Juce image behavior on MAC vs PC

Hey there, I have some widget that displays differently from mac to pc. I use a drawImage function to paint on them. If I use “fill with current brush” on PC, it behaves correctly, the pixel with >0 alpha get filled with the brush color, but on MAC, the pixel with >0 alpha get filled with the bursh color AS WELL as the outside of the image, and/or even the last or first column of pixel.

	void Rotary1::paint(juce::Graphics& g)


		g.addTransform(juce::AffineTransform().translated(-getWidth() / 8.f, -getHeight() / 4.f));
		g.drawImage(rotary, 0, 0, getWidth(), getHeight(), 0, 0, rotary.getWidth(), rotary.getHeight(), true);
		g.addTransform(juce::AffineTransform().rotated(dtr * 270 * get_value(), getWidth() / 2.f, getHeight() / 2.f));
		g.drawImage(top, 0, 0, getWidth(), getHeight(), 0, 0, top.getWidth(), top.getHeight(), true);
		g.addTransform(juce::AffineTransform().rotated(dtr * -270 * get_value(), getWidth() / 2.f, getHeight() / 2.f));
		g.reduceClipRegion(clip, get_transform_to_fit(clip.getWidth(), clip.getHeight(), getWidth(), getHeight()));
		g.addTransform(juce::AffineTransform().rotated(dtr * 270 * get_value(), getWidth() / 2.f, getHeight() / 2.f));
		g.drawImage(grip, 0, 0, getWidth(), getHeight(), 0, 0, grip.getWidth(), grip.getHeight(), true);


		juce::Path p = get_arc(-135.f, 135.f, 10.f, get_value(), getLocalBounds().reduced(getWidth() / 8).translated(getWidth() / 8, getHeight() / 4).toFloat());
		juce::PathStrokeType pst(getWidth() / 4.f);

		pst.createStrokedPath(p, p);
		p.applyTransform(juce::AffineTransform().translated(0, -getHeight() / 8.F));

		g.addTransform(juce::AffineTransform().translated(-getWidth() / 8.f, -getHeight() / 4.f));


		g.drawImage(fill, 0, 0, getWidth(), getHeight(), 0, 0, fill.getWidth(), fill.getHeight(), true);


I bet you’ll find out that it behaves differently after you have selected “Reduce motion” and “Reduce transparency” in System Preferences->Accessibility->Display.

You have to accommodate for this user setting in your designs - and also in expectations of behaviour.

Thanks for your reply! We tried enabled and disabled on mac, and kind of equivalent options on windows, the results remain the same. I got some “little” luck by checking if the sampled image portion and it’s target area were divisible per 2, but it keeps filling non existent pixel’s alpha with the current brush color, or it fills a pixel column at the end of the target area.

Ah, actually I remember there was a bug report about this recently, specifically with the power-of-two textures having ‘padding’ pixels around them … see if you can find the thread, this was discussed in detail and I believe there was a fix proposed that hasn’t made it into develop branch yet.

Well I had no luck in finding it. After further investigation, it appears that “non existent” pixels are treated as alpha = 1 on mac, and as alpha = 0 on windows. An easy way to reproduce

g.addTransform(juce::AffineTransform().rotated(45degrees , middlex, middley));
g.drawImage(the image… , true at fill with current color)

on windows you’ll see the >0 alpha filled, and only that, and on mac the >0 as well as all the exterior of the image.

and there it is. I believe it’s an oversight, but I’m kind of surprised to be the first to report this.

Yeah, we’ve seen this reported before - I remember a few weeks ago another JUCE developer had similar issues, but I’ve lost that thread in my consciousness stack - so here are some threads which might be related, and thus may have fixes (not yet pushed to develop) worth investigating:

I fixed it with transparency layers and each time reducing clip region to match the image size. It really feels like an oversight from the juce team, it’s only annoying when there’s many images to draw though. Thanks again for your help.