Comment 2 for bug 1771115

I forgot to mention why I was thinking the effect gets applied twice: I modified the neg shader to just add 0.2 to a color channel, and noticed that the effect would add up.

But now that I have experimented more with the switcher (which is where the bug is really problematic in our usecase), it seems it's not so simple. This is what I tried:

- Add a PAINT_WINDOW_ADDITIONAL_MASK mask flag to be used when there are several rendering with alpha blending on the same area, only one should not use it, for the neg plugin to know which one should apply the neg shader.
- For a start, use it in the switcher's glPaint call for the switcher popup frame, so that it's not inverted, and only the icon gets inverted.

But the transparent parts of the icon do not get inverted by neg actually: the popup frame has a grey background, and thus inversion should give another grey for the inverted transparent parts, but they just become completely white, as if the rendering of the icon was actually getting black pixels instead of the popup frame background grey color.

I then realized that BaseSwitchWindow::paintThumb uses the original application's gWindow to render the icons. I propagated the gWindow of StaticSwitchWindow::glPaint to paintThumb to use the popup frame's gWindow, but the result is the same, so I must be missing something in how rendering the icon gets the pixels behind its transparency.

But when not enabling the neg plugin (i.e. just not adding the neg shader to the pipeline), the popup frame color does show up properly in transparent areas of the icons. So it'd rather be the neg shader which does not properly get the right pixel to be used, i.e. something else to be used than gl_FragColor?