Bad drawing performance in ProTools - What's different?

Audio Plugins
1

I’m experiencing low framerate drawing my GUI in ProTools on macOS. In all other hosts it’s smooth. It gets far worse when zooming the UI larger. It’s acceptable-ish at 100%, but gets much more sluggish with larger sizes.

The GUI draws completely in a container that’s scaled with window size, almost everything is vectorized. Graphs are repainted on a 20Hz timer. There is nothing in my own drawing code that would take more time when drawing more pixels. I need to do some more debugging to find out if there’s a specific component that this is attributed to.

I suspect this could also be related to a different problem I’ve seen in ProTools exclusively:

Both issues suggest that there is some significant difference in the way the editor is drawn to screen in ProTools/AAX compared to other hosts/formats. So far I have no idea what that could be. How 'bout you folks?

2

Cool, loading the plugin in the developer build of ProTools the problem goes away. That’ll be a fun one to debug…

2 Likes
3

I’d suggest contacting Avid.

Also, notice this is a change related to macOS Core Graphics. this issue seems to start following some changes from Sonoma onwards.

4

I am having this exact issue - it appears like frame rate is low in full pro tools build but the exact same .aax in pro tools developer works great. Did you ever figure this out?

5

Still wasn’t able to fix or circumvent it. But profiling the plugin I could confirm that during or between paint calls, a lot of time is spent in some depths of CoreGraphics, so neither in my plugin, nor in Pro Tools itself.

I reported this to Avid and provided them with traces and all, and they were able to reproduce the problem and assigned it a bug tracking number. But no news since then.

6

We also spent time looking at performance issues in ProTools a little while ago. The last I heard AVID were in communication with Apple regarding the issue.

The issue required a modern version of macOS and seemed to be caused by some sources added to a CFRunLoop not being notified. We were able to prove the loop is running as expected (so this wasn’t ProTools simply taking lots f time on one iteration) but for some reason the OS wasn’t notifying sources in some cases. We were also able to reproduce the issue using Grand Central Dispatch (GCD).

The best guess is that Apple changed something about the algorithm that determines when/if a source should be notified on a particular loop and something about what ProTools was doing was upsetting that.

A couple of important things

  • We found this issue on non-JUCE plugins
  • We were able to distill the issue down to something that didn’t rely on JUCE at all

@barzachm are you using the latest version of macOS and ProTools? I just wonder if there is any possibility this has actually been addressed?

1 Like