Red glitches on some macOS setups using VSTGUI 4.9

Hi there,

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?

Best,
Ray

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.

Hi Arne,

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

Thanks.

Best,
Ray

Have you tried to invalidate the container after setting the view size?

I have, but that doesn’t change anything.

Best,
Ray

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.

Hi Arne,

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?

class TestView : public VSTGUIEditor, public IControlListener
{
public:
	const int32_t width = 400;
	const int32_t height = 400;

	const int32_t buttonTag = 1337;

	TestView(EditController *controller) : VSTGUIEditor(controller)
	{
		setRect(ViewRect(0, 0, width, height));
	}

	virtual bool PLUGIN_API open(void *parent, const VSTGUI::PlatformType &platformType) override
	{
		CRect size(0, 0, width, height);

		frame = new CFrame(size, this);
		if(frame != nullptr && frame->open(parent))
		{
			container = new CLayeredViewContainer(size);
			container->setBackgroundColor(kGreyCColor);

			CRect buttonSize(0, 0, width / 2.0, height / 8.0);
			buttonSize.centerInside(size);
			buttonSize.offset(CPoint(0, height / 4.0));

			auto button = new CTextButton(buttonSize, this, buttonTag, "Toggle", VSTGUI::CTextButton::Style::kOnOffStyle);
			container->addView(button);

			frame->addView(container);

			return true;
		}

		return false;
	}

	virtual void PLUGIN_API close() override
	{
		if(frame != nullptr)
		{
			frame->close();
			frame = nullptr;
		}
	}

	virtual bool beforeSizeChange(const VSTGUI::CRect &newSize, const VSTGUI::CRect &oldSize) override
	{
		bool result = resizeGuard;

		if(plugFrame != nullptr && !result)
		{
			resizeGuard = true;

			ViewRect vr;
			vr.right = int32(newSize.getWidth());
			vr.bottom = int32(newSize.getHeight());
			result = plugFrame->resizeView(this, &vr) == kResultTrue ? true:false;

			setRect(ViewRect(0, 0, newSize.getWidth(), newSize.getHeight()));

			resizeGuard = false;
		}

		return result;
	}

	virtual void valueChanged(CControl *control) override
	{
		if(control->getTag() == buttonTag)
		{
			CCoord yoffset = control->getValue() > 0.5? height / 2.0 : 0.0;

			if(container != nullptr && frame != nullptr)
			{
				CRect r;

				r = container->getViewSize();
				r.moveTo(0, -yoffset);
				container->setViewSize(r);

				r = container->getMouseableArea();
				r.moveTo(0, -yoffset);
				container->setMouseableArea(r);

				frame->setSize(width, height - yoffset);
			}
		}
	}

protected:
	bool resizeGuard{false};
	SharedPointer<CViewContainer> container;
};

Best,
Ray


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.

That was quick. Thanks a lot, Arne.

What about the following questions:

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?

Thanks again!

Best,
Ray

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.

Hi Arne,

Thanks for your feedback. That makes sense.

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.

Best,
Ray

Only Apple can fix this issue so I doubt it will happen for an old macOS and old machine.

Hi Arne,

okay, I understand.

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.

Best,
Ray

You can already turn it of by setting kNoCALayer in the frame config.

Hi Arne,

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.

Best,
Ray

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.

1 Like

Okay, got ya. Thanks.

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?

Thanks.

Best,
Ray

Maybe the same issue as VSTGUI on other hosts - #11 by MarkusK1