Performance issues with Core Graphics

[bx_joscha]

Hello,

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?

Regards,

Joscha

[bx_joscha]

This bug is also reproducible by adjusting a single CControl, for example CKnob. While adjusting a CKnob, the whole window gets redrawn, redundantly.

[Arne Scheffler]

Hi Joscha,
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:

Code: Select all

	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)
		{
			[nsView setWantsLayer:YES];
		}
	}

Cheers,
Arne

[bx_joscha]

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.

[Arne Scheffler]

Hi,
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 ?

Cheers,
Arne

[bx_joscha]

High Sierra.

[bx_joscha]

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/prod ... ole_n.html).

[ray]

Hi Joscha,
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:

Code: Select all

	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)
		{
			[nsView setWantsLayer:YES];
		}
	}

Cheers,
Arne

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. 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.

[bx_joscha]

I wonder if that means that from macOS 10.11 and VSTGUI 4.6 onwards CLayeredViewContainers become completely obsolete?

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.

[ray]

I wonder if that means that from macOS 10.11 and VSTGUI 4.6 onwards CLayeredViewContainers become completely obsolete?

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.

Hi Joscha,

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.

Best,
Reimund