Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels
Submitted by Daniel Boles
Assigned to Xorg Project Team
Description
This was originally reported against GTK+ here: https://bugzilla.gnome.org/show_bug.cgi?id=774270 A primary developer for rendering on GTK+ believes this to be an issue in Cairo or the X driver. So I'm moving it here. I hope there's enough info to do something useful. Unfortunately my knowledge of the tech involved is pretty minimal at this point, but I'll try any tests you want!
Basically, by nesting GtkFrames that had identical RGBA components in their background colours and 0 < alpha < 1, I found that child widgets of the innermost frame would not properly draw its background colour as they should. Rather, they would intermittently draw the background colour of an earlier/uppermost frame... although this would flicker to/from the correct colour through such actions as hovering over the widget or resizing the window.
By noticing some inconsistencies in when this occurred, I came to realise that by ensuring each successively nested frame's background colour differs from its parent's by at least 1 point (on a 0~255 scale) in at least 1 of the RGB components, then this problem can be worked around. However, if 1 or more of the nested frames' bg colours are the same, things start glitching out.
Running the test case with GDK_RENDERING=image to achieve the following...
Always create image surfaces. This essentially turns off all hardware acceleration inside GTK. ...also bypasses the issue.
I've tried to run this in Xvfb in an attempt to narrow down whether it's Cairo or X but haven't gotten anywhere fast yet.
Again, let me know anything I can do to help diagnose (or redirect) this. Thanks!