[cairo-bugs] [Bug 99233] New: Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99233

            Bug ID: 99233
           Summary: Nesting backgrounds with identical RGBA causes wrong
                    colours to be drawn at innermost level
           Product: cairo
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: xlib backend
          Assignee: chris at chris-wilson.co.uk
          Reporter: dboles.src at gmail.com
        QA Contact: cairo-bugs at cairographics.org

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!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20161230/e3b51a63/attachment.html>