UI performances of a 3rd party VST hosted inside a JUCE VST

windows

#1

Hi,

I’ve written a VST with JUCE that hosts another VST (like an effect rack).
The hosted VST UI is opened in a sub window owned by my pluginEditor.

However, on Windows, when I open UI-heavy VSTs (such as Serum on some presets), the UI lags a lot. Borderline unresponsive. Sound is not affected though.

So, for instance, opening Serum directly into Maschine works fine, even on heavy presets.
Opening Serum inside my VST “wrapper” makes its UI lag on heavy presets.
Same code in Maschine on osx, no problem.

Looking at the profiler in VS2017, it seems the “idle” calls that are sent to Serum on a Timer by the VST wrapper take all the resources. So obviously, Serum is drawing stuff that is CPU intensive. Commenting the idle calls from the wrapper relieve the CPU, but then of course the UI is not updated.

Is there an optimization to do for an hosted VST to run as smooth in another VST as when directly instantiated by the DAW on Windows? Something in the linker? Or related to OpenGL?


#2

I made a PIP (9.5 KB) for anyone to easily try on windows,
and a video to demonstrate the problem: https://youtu.be/ZB33YGZ9DrY
If you watch the keyboard in Serum, you’ll see that the first preset does update the view, while the second one is pretty slow and the third one almost stalled.

Since Serum doesn’t have this slowing down when directly hosted in a DAW, or even when hosted in other VSTs like Maschine or Blue Cat Patchwork, I believe there is either something wrong in JUCE or in the way I make use of it.


#3

Possibly the same issue as this? Should be a high priority for the JUCE team, imo.


#4

Possible…

Although in my example PIP I don’t use any OpenGL in the main window. If I’m not mistaken, the default renderer is a software renderer. Unless it automatically uses OpenGL behind my back?

And the VST “idle” callback that the plugin (here Serum) relies on to repaint its UI is running on the main thread… So if it uses OpenGL to render its curves, I don’t see what’s in its way : it has no other OpenGL context to compete with, and already in the main thread. Confusing :thinking:


#5

RenderDoc says the Serum window is D3D11, so it’s probably not related.