Juce image behavior on MAC vs PC

[nfect]

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.setColour(draw_colour);

		g.beginTransparencyLayer(1.f);

		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);

		g.endTransparencyLayer();
		g.beginTransparencyLayer(1.f);

		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.reduceClipRegion(p);

		g.setColour(color_fill);

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

		g.endTransparencyLayer();
	}

[austrianaudioJV]

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.

[nfect]

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.

[austrianaudioJV]

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.

[nfect]

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.

[austrianaudioJV]

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:

Subtle drawing bug(?) -> fillRect (integer version) scaled

Because I think this is still an issue, here a simple demo to reproduce the issue The code will render differently on Mac and Windows (both with same physical pixel scales). [Differences] class BoxDemo : public juce::Component { public: BoxDemo() { setTransform (juce::AffineTransform::scale (1.33)); } void paint (juce::Graphics& g) { g.fillAll (juce::Colours::white); g.setColour (juce::Colours::black); g.fillRect (10, 2, 2, 2); g.fillRect (20.f, 2.…

BR: fillAll doesn't fill all

But it’s still clipped by the low-level context regardless of what rectangle you feed into the fillRect call. You can safely feed {-10000,-10000, 1000000, 1000000 } in there, and it will be correctly clipped. Or do you think that any fillRect automatically just does that, regardless of the clip rect and then overstomps memory like crazy?

Alpha channel rendering

Hey All, I am having a few issues rendering alpha channels from JUCE into OpenGL textures. Specifically, the issue is with anti-aliasing. Please look at these tests, where I am loading a PNG image with transparency into an OpenGL texture. You will see white text on a color background. The text is the texture image (white text on transparent background), the background color is made by OpenGL. In this example, the PNG is loaded with JUCE’s ImageFileFormat::loadFrom, and then sent to OpenGL: h…

[nfect]

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.