Something is wrong with colour blending when opacity is involved

[Matt_SF]

@d-healey ah, that's odd... here's what I get

[tomekslesicki]

Thanks guys, I'm getting the same problem with Matt's snippet, unfortunately.

@d-healey maybe you're right about the opacity stack, but then if 1 is 100%, isn't it a bug that if a semi-transparent layer is overlayed on top of a layer that already is fully visible, the opacity can go above 100%?

[d.healey]

@tomekslesicki Yes it does seem a little strange

[Christoph Hart]

Alright, either my monitor is not calibrated correctly or I'm getting blind, but I don't see any difference and this entire topic looks like a big prank to me :)

Can somebody make a clear example that shows the difference like night and day type (and not a colour that is 0xFF292929 but should be 0xFF292928.

[tomekslesicki]

@Christoph-Hart it's not about night and day, it's just that if it's about creating an impression of a half-opaque panel with controls, it doesn't look good if there's suddenly a rectangle overlaid on top of the panel.

[Christoph Hart]

@tomekslesicki But where is the rectangle? I don't see a rectangle.

[d.healey]

@Christoph-Hart

But where is the rectangle? I don't see a rectangle.

Must be a monitor (or eyeball) setting issue :p the rectangle is subtle. I'll see if I can make a clearer example.

[d.healey]

This post is deleted!

[d.healey]

Ok here's something interesting.

Alpha values

0.1 = No rectangle
0.2 = No rectangle
0.3 = Rectangle
0.4 = No rectangle
0.5 = Rectangle
0.6 = No rectangle @tomekslesicki Maybe just use this value
0.7 = Rectangle
0.8 = No rectangle
0.9 = Rectangle

Here I have taken the same snippet as before and adjusted the contrast in an image editor

[tomekslesicki]

@d-healey thanks, David, you're way better at explaining things than I am!

[Christoph Hart]

@tomekslesicki Ah finally - actually I think that the PNG compression of the screenshot makes the differences even more subtle, but now I have finally proof that you aren't executing an elaborated prank :)

Alright, the minimal use case to demonstrate this issue is:

const var Background = Content.getComponent("Background");

const var backgroundgrey = 0xFF333333;

Background.setPaintRoutine(function(g)
{
	g.fillAll(backgroundgrey);
	g.setColour(Colours.withAlpha(backgroundgrey, 0.6));
	g.fillRect(this.getLocalBounds(50));
});

I've deliberately used a pure grey in order to rule out rounding errors. For me, 0.6 creates the most visible rectangle. Curiously, in a raw JUCE component, it doesn't show that rectangle, so I'll try to check where the error comes from.

[Christoph Hart]

Curiously, in a raw JUCE component, it doesn't show that rectangle

Nope, my weak eyes struck again, it's actually the same when using raw JUCE.

auto grey = Colour(0xFF333333);

g.fillAll(grey);
g.setColour(grey.withAlpha(0.6f));
g.fillRect(getLocalBounds().reduced(50));

Also shows up that box. Now it gets complicated :)

[Christoph Hart]

I've posted it in the JUCE forum, let's see how it goes.

Subtle colour error

Hi everybody, it seems that the graphics renderer behaves a bit weird when drawing the same colour over itself with a different alpha value. The best way to reproduce this is this example code: auto grey = Colour(0xFF3…

JUCE (forum.juce.com)

I wouldn't hold my breath that there is an easy solution for this though...