since we have updated our VSTGUI code to version 4.6, we encounter massive performance problems on MacOS, also in Cubase. Using the Xcode Graphics Tool Quartz Debug, one can see that all plugins with meters get redrawn completely each frame. Of course, the meters need to get redrawn, but now also the whole frame gets redrawn redundantly. This was not the case with VSTGUI 4.3, which we use for our currently released products.
My problem is that I am having trouble nailing down the problem. Did anyone of you see similar effects using the latest VSTGUI code state?
first of all the Quartz Debug tool does not work any longer correctly. It does not show the dirty rectangles which gets redrawn since we render into a CALayer. The switch to CALayer showed significant better performance here, but maybe your use-case is different. You can try to turn off using the CALayer code path and see if it is the reason of your performance problem. Fastest way is to disable the following code in nsviewframe.mm:
auto processInfo = [NSProcessInfo processInfo];
if ([processInfo respondsToSelector:@selector(operatingSystemVersion)])
auto systemVersion = processInfo.operatingSystemVersion;
// on Mac OS X 10.11 we activate layer drawing as this fixes a few issues like that only a
// few parts of a window are updated permanently when scrolling or manipulating a control
// while other parts are only updated when the malipulation ended, or CNinePartTiledBitmap
// are drawn incorrectly when scaled.
if (systemVersion.majorVersion >= 10 && systemVersion.minorVersion > 10)
Thank you so much, Arne, for your quick reply. This is exactly the code that causes the performance issues. Deleting these lines fixes our bugs. By the way, are you really sure Quartz Debug is not working correctly? I currently assume that it perfectly reveals the problem of the code lines. Our use-case is creating audio plugins for Cubase, etc. We are doing nothing special.
yes I’m sure that Quartz Debug does not work any longer when using a CALayer.
By the way, you should find a way to make your UI work with the CALayer stuff as this is the way to go. The next macOS version will implicitly set the layer to be active.
On what macOS version did you see this performance issue ?
This whole thing is really interesting and a strange situation. A few years ago, we discussed that VSTGUI might need a code like that. We thought that using CALayer is the way to go. We encountered massive performance problems. Then, Apple announced a major MacOS UI framework rework that fixed our problems. When I debugged our plugins I could see that Apple managed to move our VSTGUI-based UI’s on Core Animation. That was a good thing for our performance. It is really strange and I do not understand, why your code causes this trouble. As you already mentioned, Apple managed to activate CALayer for all UI’s, so it should not make any trouble to “want a layer”. But anyway, we see a drastic performance lack for large-scale UI’s such as bx_console N (https://www.plugin-alliance.com/en/products/bx_console_n.html).
I wonder if that means that from macOS 10.11 and VSTGUI 4.6 onwards CLayeredViewContainers become completely obsolete?
I am in fact successfully using CLayeredViewContainers in my UI implementations to come by performance issues on Mac. I have to workaround plenty of stuff, though: e.g. https://sdk.steinberg.net/viewtopic.php?f=5&t=77 which I never received any feedback on, CScrollView and other utility views inherit from CViewContainer, CSplashScreen doesn’t support CLayeredViewContainers either and offsetting a CLayeredViewContainer isn’t supported, out of the box (used for collapsible GUIs e.g. Black Rooster Audio Magnetite, which currently has to be worked around by invalidating the entire view in an idle timer when the GUI is collapsed ). There was also a customer that reported black flickering rectangles / refresh issues on his Mac, that could be removed by falling back to CViewContainers, which only seems to happen with specific graphic hw. With Joschas report on the newly (?) introduced performance issues this all becomes a little puzzling so an official clarification would be extremly appreciated.
Did you evaluate the performances with and without explicit using of layered view containers? Perhaps you can do some quick hacking to build two versions of a plugin to compare them by commenting out setWantsLayer in the platform code. It would be very helpful to understand if the use of layered view containers really pushes the performance. Currently I am very skeptical, because of the latest experiences with the use of setWantsLayer.
I can do some quick tests probably early next week. My previous findings (this happened when migrating to VSTGUI 4.5 with the Rooster stuff iirc, the same goes for the Fuse plugins which are currently on 4.6) showed that using CLayeredViewContainers instead of CViewContainers really helped performance-wise, e.g. sluggish automation, UI related CPU load bursts and slow DAW meter refresh went away for good, but it took a lot of working around other issues as mentioned above. My systems were on 10.10 back then, currently I only have access to a 10.13.5 and 10.12 system, but I’ll get back to you with further reports asap.
That is very interesting, because our QA also reported performance boosts in some situations, e.g. automation, in few hosts. But in many cases and hosts, e.g. Cubase, the performance went so bad, that the plugin became nearly unusable. I personally was able to reproduce the performance lacks and they were really bad. So, maybe setWantsLayer is still the way to go, but the VSTGUI framework does not handle it right? It would be very appreciated if Steinberg could give some details here, how to proceed to always to get the best performance.
So far I didn’t get any customer reports regarding impaired UI performance in the Fuse Audio Labs plugins. Then again, these plugins do not have any really big UIs. I’m not part of the Black Rooster Audio team anymore so I can’t say if there have any support tickets in this regard, but a bigger CLayeredViewContainer based UI implementation for reference would be the Magnetite in the non-collapsed mode (SIC: It seems they went for a CViewContainer since v2.2 to get rid of the mentioned flicker/refresh bug).
Btw. my own investigations/profiling sessions are already a little while ago, so the situation may since have changed macOS wise. There will be a bigger Fuse Audio Labs update soon which involves a full regression test and I’ll ask my Betas to have an eye on this. I’ll also let you know about my own findings asap.
One more idea: Maybe your issues have to do with a memory limit that is hit? I know you you store your GUI graphics in PNG-8, but that doesn’t really matter once they’re decoded into RAM / Graphics RAM where they reside in 32-bits ARGB/RGBA. In terms of memory requirements the bx_console plugins are quite heavy I assume. Maybe try removing graphic resources, successively and asses what happens using the activity monitor and/or instruments? Just a guess…
On my Mac Book Pro (Retina, Mid 2012, 2.6GHz i7, Intel HD Graphics 4000), macOS 10.13.4, I can’t see any significant difference in terms of CPU load between CViewContainers or CLayeredViewContainers. Which kind of corresponds to what Arne is saying. It’s only when I pass an additional kNoCALayer to my CFrame’s open function like this, that things become slightly worse:
Which is essentially identical to commenting out the “[nsView setWantsLayer: YES];” portion in nsviewframe.
So it’s actually the other way around in my case. However, this was just a quick test session using a single F-59 instance in REAPER64 and macOS’ built-in activity monitor to measure CPU load.
You already mentioned that it may be restricted to a certain setup / host environment, though.
Maybe it’s something specific your plugins’ code? I don’t recall the BX code too well, but iirc meters were polled and updated in your editor’s idle(). What if you remove that for a try?
Since you can reproduce the issue easily on your machine, can you maybe try installing the Fuse Audio Labs F-59 which has a slightly bigger GUI and see whether it also slows down your host as described?
I cannot reproduce it with your plugins. I can only reproduce the performance problems as soon as there are meters attached that are regularly updated. If I load a VST2 plugin (no silence flag) including meters into Cubase, the bug becomes very obvious.
Here is a video that shows how the plugin UI slows down the whole system including the host playback visualization:
I’m talking about Arne’s hint on setDirty() instead of invalid() on the UI thread. But again, I’m just guessing here.
I would be highly interested in your findings once you finally tackle that issue on your end. Maybe it helps others, as well. At least it seems that using CViewContainers and derived views out of the box is the way to go / the way intended by Steinberg, so I can eventually get rid of those CLayeredViewContainer workarounds I’ll keep my mouth shut now.
Do you have the UI Size set to “Normal (100%)”? Otherwise, this is a known issue mentioned under https://www.fuseaudiolabs.de/index.html#faq which affects non-highDPI displays on mac os and which will be fixed in one of the next builds.
Does the plugin run in 32 bits (check e.g. the “About…” info in the plugin menu)? 32Bits VST2 is Carbon on Mac (unless you support REAPER’s cockos extensions, which I don’t). If so, does the UI look better in VST3 or 64 bits?