Extremely laggy GUI in Cubase 11 / macOS when dragging components – NSViewComponentPeer::toFront seems to be the issue

We got a lot of Cubase 11 user reports where the GUI of our recently released plugin becomes extremely laggy – barely usable – when components are dragged around. The beachball appears and depending on the system, it takes up to some seconds until the GUI becomes responsible again. It took us some time to reconstruct this issue, since it does not occur on every machine.

After finally finding a mac where the problem appears, profiling revealed that at the timepoints where this happens, the message thread is frequently blocked for a long time and that this code path seems to be the culprit:

And indeed, simply commenting out these lines in NSViewComponentPeer::toFront lets the issue disappear:

if (isSharedWindow)
    [[view superview] addSubview: view
                      positioned: NSWindowAbove
                      relativeTo: nil];

Disabling OpenGL for the plugin also lets the problem disappear. Currently, we only see this issue in Cubase 11 and no other host.

I don’t know anything about the native macOS GUI APIs, so I don’t even know exactly what the commented out block of code is actually doing and why it is necessary. The plugin seems to keep working as expected on a first glance. Finding this was pure try & error driven luck after examining the profiling data.

I’m not sure if I can make up a simple plugin to reproduce this issue, since I cannot even reproduce the issue with our plugin on my machine, but I’ll try my very best. In the meantime, does this ring a bell to any of the JUCE devs? We would be highly interested to get this fixed soon since this seem to affect a huge number of Cubase users which are not very happy with the state of things at the moment :grimacing:

Thanks in advance!

5 Likes

I found this to be the case with OpenGL, Mac and cubase, also.

For me, setting continuous repaint to false, and triggering the repaint via a timer fixed this issue.

It seems to be triggered when the JUCE graphics class paints to the OpenGLContext. If you only render in OpenGL vertex buffers, it’s fine. The second you attach the context to handle component rendering, things get weird.

Just to be sure: So you can confirm the exact scenario described above? A freezing UI when clicking/dragging components only in Cubase 11 while e.g. Cubase 10 runs completely smooth and the UI generally renders smooth when nothing is clicked?

Generally speaking, we tuned our OpenGL performance a lot over the last years, especially triggering the repaints from a timer as you suggested turned out to be a quite bad idea since this showed a massive performance decrease especially on Windows when multiple plugin editors were opened. Generally, our plugin GUI renders fine also in Cubase 11 if you are not clicking on it. I’d really like this thread to not become a general OpenGL tuning discussion but stay focused on the particular issue described in detail above – with all suggestions and explanations regarding this particular issues being highly welcome of course :slight_smile:

I’m quite curious about if this might be something similar that affects the VST3 of Vital (and Diablo Lite), but not the VST2. Vital is definitely using JUCE, but I’m not sure about Diablo Lite (and I can’t remember if they have a VST2 to test this “theory”, but the symptoms are exactly the same, eg. entirely unusable due to UI lag in Cubase only).

Do you have a VST2 of your plugin?

I had this issue in 10.5, I will test 11 in the coming days. But the issue was as you described, ui renders fine until you interact with anything via clicking/dragging. Mac and cubase only. I’ll see if commenting out that block also fixes it here.