We recently updated to the latest VST3 SDK including VSTGUI 4.9 and now some users are reporting weird red glitches where pixels should be transparent on some macOS setups - see attached screen shot. It happens e.g. on a Mac Pro running macOS 10.14 and Radeon RX580 8GB graphics hardware, but not on a 2012 Mac Book Pro running 10.13, a Mac Mini 2011 running 10.14 or a 2020 Mac Book Pro M1 running 11.0.
The affected view is a CMovieBitmap, but also shows around the borders of CAnimKnobs embedded in a CViewContainer. It goes away once we switch to CLayeredViewContainers, which seem to have their own issues, however, i.e. they can’t be combined with CSplashScreen or they can’t be offset without failing to redraw properly.
The same code / graphics seemed to perform flawlessly using VSTGUI 4.6.
Has anyone else experienced that? Is Steinberg aware of this issue?
Hi,
we are not aware of this issue. The only change in this area was enabling asynchronous layer drawing.
Do you have more reports beside the MacPro + Radean RX580 about this issue?
By the way, I know about the issue with the CSplashscreen but not about the offset issue in CLayeredViewContainers. Can you hook up an example so that I can have a look? I use them in some cases and I never had an issue with offsets.
So far I have only received reports where the ATI Radeon chipset seems to be causing the issue.
Regarding the offsets, here’s a minimal sketch. We have some GUIs where the top-part of the GUI can be collapsed. This is achieved by offseting the GUI container and resizing the plugin window, accordingly:
CCoord dy = collapsed? topOffset:0;
if(container)
{
CRect r;
CPoint p(0, -dy);
r = container->getViewSize();
r.moveTo(p);
container->setViewSize(r);
r = container->getMouseableArea();
r.moveTo(p);
container->setMouseableArea(r);
}
setSize(CPoint(hBackground->getWidth(), hBackground->getHeight() - dy));
The GUI doesn’t get redrawn properly, if container is a CLayeredViewContainer and if it has an offset != (0, 0).
Will the CSplashScreen issue be fixed at some point btw.?
Can you try to build an example? I tried to reproduce this issue here just with the uidescription editor by adding a layered container and it just works with any offset I throw at it.
Below is a minimal example and some screenshots demonstrating the behavior depending on whether a CViewContainer / CLayeredViewContainer is used. This happens in all formats and hosts on macOS. The GUI turns to black when collapsed in case of a CLayeredViewContainer. I see similar refresh issues when attaching a CScrollView to a CLayeredViewContainer.
What’s the advantage of using asynchronous layer drawing btw.? Performance, I assume.
Would it be feasible to add a flag to the optional IPlatformFrameConfig object passed via CFrame::open() that controls whether async layer drawing is used?
OK, I was able to fix the layered container issue now. This was of course only happening if you move the layered container into the negative top left position and only if not embedded in a scroll view. You can pick this change into your sources for a fix.
What’s the advantage of using asynchronous layer drawing btw.? Performance, I assume.
Would it be feasible to add a flag to the optional IPlatformFrameConfig object passed via CFrame::open() that controls whether async layer drawing is used?
Asynchronous layer drawing is the only way to get acceptable UI performance on retina displays in current macOS versions.
If you want to turn this off in general, then you can for now disable this code. I will check adding this as an option for the next release.
If these red glitches could be fixed on your end that would be great, of course. So we could just use asynchronous drawing in all cases and not care about the hardware/OS version the plugins are running on.
I also had a customer who’s on Catalina (10.15) and using a Intel HD Graphics 630 chipset. I’m sure it’ll affect more people once developers will update to the latest VST3 SDK / VSTGUI, so an option to turn the asynchronous layer drawing off, even if it negatively impacts performance, would be highly welcome.
Yes, but what if I want to force synchronous, layer based drawing as in previous versions of VSTGUI. This wouldn’t be available in the current version. I’m thinking about two separate flags, e.g. kNoCALayer, kSyncCALayer.
Since macOS 10.14 all views are drawn layer based, you cannot turn it off. So the kNoCALayer just prevents asynchronous drawing on macOS 10.14 and newer.
I know this is a different issue, but allow me to post it here instead of opening a new thread: I have another report according to which a customer is having refresh issues on a Windows 10 machine equipped with an ATI Graphics Card and the latest AMD driver.
The GUI displays black rectangles in areas where it was covered by another window when brought to the front. You have to close and re-open the plugin window in order to make these glitches disappear. This happens in both Studio One and FL Studio, which makes it seem like this is host unspecific.
The issue was not present in the previous build of our plugins and the GUI client code did not change so it’s likely related to the VSTGUI update (v4.6 → v4.9). Were there any changes in the D2D backend implementation that this could be related to?