Bug? Scrolling in preset/cab browser is painfully slow

fractalz

Power User
Scrolling through presets or cabs in the browser window is very slow / laggy on the Mac. This occurs on a Mac Pro and Macbook Pro (retina).

As slick as Axe-Edit is, using this window always frustrates me since it is so terribly S L O W.

I'll attach a sample of the process during scrolling, which shows lots of time spent drawing.
 
It looks like I can't paste a sample into the forum - it is too long.

However, this should be easy to observe on just about any machine.

I did run an Instruments trace on Axe-Edit and it points to PresetListContent::paint() as the culprit. That function pegs my CPU drawing images via juce::Graphics::drawImage() while scrolling in the browser.
 
What version of axe edit? What Mac OS? What axe firmware?

When you say "browser" are you referring to Axe-Manage?

It is not slow for me at all - latest fractal versions, latest Mavericks (and Yosemite public beta) on a late 2013 iMac and 1st gen 13" retina MBP.
 
Sorry, forgot to post my config:

Axe-Edit 3.1
Axe-FX II XL running 15.07
Mac Pro 13,1 with ATI Radeon HD 5770 GPU
Mac OS 10.9.4

I also experience this on my early 2013 Macbook Pro Retina running 10.9.3

By "browser" I'm referring to the windows that show up when you:

- press the "Presets..." button next to the preset number
- select Tools > Axe-Manage Presets
- select Tools > Axe-Manage Cabs

It's been this way since I started using Axe-Edit on my MK II and now on my XL (possibly worse on the XL due to the larger preset / cab lists).

To say it is slow is being kind. If I swipe on the Macbook trackpad or on my Magic Mouse, the scrolling action lags behind about 1/2 second and then takes about 2-3 seconds to finish scrolling. If I click and drag the scrollbar handle, it cannot keep up with the mouse at all.

I could post a video if needed but it may be hard to capture the mis-behavior. As I mentioned above, it takes over one of my CPUs 100% if I scroll the view back/forth so that tells me there is something amiss.

Thanks,
fractalz
 
BTW - both of my machines run in HiDPI retina mode (1280x800 on a 30" monitor on my Mac Pro). It seems to be worse in retina modes but is also slow in non-retina display modes.
 
I just tested this as well on the latest gen Macbook Air, and latest Macbook Pro Retina 13. I'm running 10.9.4, axe edit 3.1 and can't reproduce the problem you are seeing. Have you tried creating a new account on your mac and testing axe edit there?
 
Thanks for looking into this.

I can reproduce this 100% on a second account on the Mac Pro.

It is also easy to reproduce if I run my 30" monitor in its native resolution (2560x1600) and run AxeEdit in its Full Screen view.
 
Note, this is reproducible at 1:1 resolution but the lag is not as dramatic. However, I can still easily get the mouse pointer to decouple from the scroller.

This relatively simple view should be able to scroll at 60 FPS with no issues keeping the mouse at the same position on the scroller during the scroll. If you have access to Xcode, you should download the Graphics Tools package and watch the frame rate using QuartzDebug (Window > Frame Meter). I'm getting about 5 FPS on my 30" display with Axe-Edit running in full screen mode at 2560x1600. At 1:1 I'm getting about 20FPS. Compare to scrolling a Safari window and you'll see it go up to 60FPS no problem.

If you Disable "Beam Sync" (i.e., don't wait for the vertical refresh sync signal to draw) you'll be able to see the max repaint speed of the app. Safari updates at 90+FPS and Axe-Edit gets to 30FPS in 1:1 mode. So, again, it seems like there is some very inefficient drawing going on.
 
Here's a video showing the frame rates mentioned above. Note that it is a bit slower since I'm also recording the screen. Watch the FPS gauge at the lower-left corner of the screen.

https://s3-us-west-1.amazonaws.com/fractalz/Axe-Edit+FPS+1080p.mov

There is also a pause when I first go to full screen mode and the view does not scroll at all - I'm getting 10 FPS drawing the scroller but no text is scrolling. Once it does start scrolling the text, it's at 3-4 FPS.
 
I don't know anything about this JUCE library that is used for the Axe-Edit UI, but I found this post about their renderer:

GL image rendering improvement | JUCE C++ Library

The claim is that their GL renderer runs ~250x faster than the CG renderer by caching images on the GPU. Sure enough, the time spent in Axe-Edit is in the CG renderer drawing images:

+ ! 340 juce::Graphics::drawImage(juce::Image const&, int, int, int, int, int, int, int, int, bool) const (in Axe-Edit) + 232 [0x4cd52]
+ ! 340 juce::Graphics::drawImageTransformed(juce::Image const&, juce::AffineTransform const&, bool) const (in Axe-Edit) + 109 [0x4cb5d]
+ ! 340 juce::CoreGraphicsContext::drawImage(juce::Image const&, juce::AffineTransform const&) (in Axe-Edit) + 39 [0x6154b]
+ ! 340 juce::CoreGraphicsContext::drawImage(juce::Image const&, juce::AffineTransform const&, bool) (in Axe-Edit) + 1120 [0x61226]
+ ! 340 CGContextDrawImage (in CoreGraphics) + 429 [0x924ab30c]

Anyway, hopefully one of the Axe-Edit engineers will take a look at this info.

This performance lag is not just the text window, although it is more pronounced there. I see similar FPS speed limits when dragging things in the layout view. For example, drag one of columns around (so you are dragging all four blocks) and it will not keep up with the mouse pointer.
 
Back
Top Bottom