VSTGUI 4_10_3 red bitmaps?

Developer VSTGUI
1

Hello,

After upgrading to VSTGUI 4.10.3 we have reported issues from some users that some bitmaps are red for OSX:

plugin_red_squares
plugin_red_squares1920×2560 730 KB

Of course it should look like the knob below, but for some reason it doesn’t. If bitmap wouldn’t be found in the system, there would be just transparent sections.

Of course this could be still case specific to our environment, but what is strange that we have just one report, and there are only 2 knobs that don’t work properly - of coruse most of thoe are quite similar when it comes to structure - what makes it odd, and point to some strange corner case.

Of course - live is live and we can’t reproduce it on about 10 machines, so it is not easily reproducible and most likely connected to some sort of GPU driver, or GPU HW.

I don’t exactly recall what version we were on prevsiously, but it worked without any issues - if there is anything that someone can point to, it would be greatly appreciated.

Thank You!
Michal.

2

Strange thing is that it seems to happen only on Radeon RX560 - we have two reports - one on Mac Pro 5.1, and second one on Mac Book Pro - both with exactly the same chip. Any hints?

3

In case you haven’t figured it out yet: we have seen these kind of glitches only with asynchronous drawing enabled and on non-high dpi displays.
Also have a look at this thread, seems to be exactly your issue:

4

Hi together,
we also have issues with red rects together with big potistack images (with a height greater than 23000 px). Luckily I am able to reproduce them on my development system (tested with VSTGUI 4.9 and 4.11).
As I wanted to see if this is VSTGUI related or on baseSDK side I created a minimal App based on the VSTGUI implementation and was also able to reproduce it.
So i reported that bug together with the example to apple, and they identified a not intended modification of the layer property of the view. “This layer is normally considered the property of AppKit and it is possible that your efforts to use it may be confounded by AppKit’s assumption that it owns this layer and has full control of the layer all to itself. To avoid that possibility, I suggest adding your custom layers as sublayers to the view’s layer. Then you can have full control over them without the possibility of AppKit making changes.”
They modified my example and with that I am not able to reproduce that bug anymore. (modification is encapsulated via USE_CUSTOM_LAYER).

self = [super initWithFrame:frame];
	if (self) {
		self.wantsLayer = YES;
#if USE_CUSTOM_LAYER
        self.customLayer = [[CALayer alloc] init];
        self.customLayer.drawsAsynchronously = YES;
        [self.layer setDelegate:self];
        [self.layer addSublayer: self.customLayer];
#else
		self.layer.drawsAsynchronously = YES;
#endif

Can you give feedback if a similar solution in VSTGUI would be possible to solve that issue? I can also provide the minimal example if needed. Meanwhile I will try implementing this in a local checkout of VSTGUI if possible.

Thx, Matthias

5

Hi Matthias,
thanks for this work. I’ve modified the current develop branch to use a custom layer instead of the NSView.layer. Please see the calayer-red-rects branch. Can you test that this fixes the issue for you?

Cheers,
Arne

6

Hi Arne,
thanks for the quick reply. I tested it and this unfortunately does not help. I think there is also a switch to another CB needed: from drawRect to drawLayer, this callback brings its own rendering context. I attach the AppDelegate.m from the example project which Apple modified. They did everything which is encapsulated in the preprocessor command USE_CUSTOM_LAYER.

AppDelegate.m.zip (2.0 KB)

Best,
Matthias

7

Hmm, did they tell you what the real issue is with the current implementation? And in your example, how big is the potistack_big.png image?

8

Hi Arne,

I currently know what Apple sent to me:
"Another small item is that your code is modifying the layer property of the view. This layer is normally considered the property of AppKit and it is possible that your efforts to use it may be confounded by AppKit’s assumption that it owns this layer and has full control of the layer all to itself. To avoid that possibility, I suggest adding your custom layers as sublayers to the view’s layer. Then you can have full control over them without the possibility of AppKit making changes.

I modified the test sample you provided so you can switch between the two approaches for using layers to see if that makes any difference on the particular machine you are using for testing. Please try testing with the two different approaches to see if that makes a difference for you."

…and at the end exactly this makes the difference. With the additional layer approach I cannot reproduce the red rect bug.

I am able to reproduce that with two different pngs, 228x23028px and 240x29040px.

Best,
Matthias

9

Hi,
after a research with Arne this topic ended with no longer using unusual image sizes for the stack poti images.
When i realign the stack images from 1x101 subimages (228x23028px) to 10x11 subimages (2280x2508px) and switch to the new CMultiFrameBitmap from the feature branch multi-frame-bitmap the red rects problem is gone.
It will also most likely solve the limitation on Windows where images cannot be wider and higher than 16k px (see thread issues-with-large-bitmaps-on-windows-using-vstgui-4-10).

When the feature CMultiFrameBitmap is released we will switch to it.

Thx Arne for the support.

Best
Matthias