Bug 58632 – REGRESSION(75137): directly composited images are double-drawn sometimes

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[James Robinson]

Load http://trac.webkit.org/export/83947/trunk/LayoutTests/compositing/direct-image-compositing.html in a WebKit nightly or chromium.  The first, third, and last images render incorrectly until the window is resized - it appears that the image is composited on top of itself and so the semitranslucent parts of the image look too dark.  Forcing a repaint of the root window (by resizing the window or whatnot) seems to fix it.

I can't reproduce in Safari 5.0.4, so guessing that this regressed at some point.

[Simon Fraser (smfr)]

Would be good to know when this regressed.

[Simon Fraser (smfr)]

<rdar://problem/9289398>

[James Robinson]

bisect-builds says http://trac.webkit.org/log/trunk/?rev=75294&stop_rev=74229 - sadly large range.

[James Robinson]

Tighter range (using chromium continuous builds): http://trac.webkit.org/log/trunk/?rev=75164&stop_rev=74761.  Perhaps http://trac.webkit.org/changeset/75137 ?

[Simon Fraser (smfr)]

That's possible.

[Simon Fraser (smfr)]

I narrowed this down to between r75123 and r75154.

[James Robinson]

Confirmed that reverting 75137 locally fixes the bug.

[Chris Marrin]

Created attachment 90959 [details]
Patch

[James Robinson]

Comment on attachment 90959 [details]
Patch

It should be possible to construct a pixel test for this, right?

[Chris Marrin]

(In reply to comment #9)
> (From update of attachment 90959 [details])
> It should be possible to construct a pixel test for this, right?

You'd think. I tried and failed. Running in DRT doesn't show the error. I assume that's because DRT does funny rendering tricks to get a consistently sized window, which must change the ordering and avoid tickling the bug. Of course that might make my claim that https://bugs.webkit.org/show_bug.cgi?id=59352 would allow us to test this logic.

[Chris Marrin]

Committed r84856: <http://trac.webkit.org/changeset/84856>

[Chris Marrin]

(In reply to comment #10)
> (In reply to comment #9)
> > (From update of attachment 90959 [details] [details])
> > It should be possible to construct a pixel test for this, right?
> 
> You'd think. I tried and failed. Running in DRT doesn't show the error. I assume that's because DRT does funny rendering tricks to get a consistently sized window, which must change the ordering and avoid tickling the bug. Of course that might make my claim that https://bugs.webkit.org/show_bug.cgi?id=59352 would allow us to test this logic.

(to finish that sentence)

That would make my claim that ... would allow us to test this logic suspect. There may be no practical way to do a good test for this bug.