Bug 58632 - REGRESSION(75137): directly composited images are double-drawn sometimes
Summary: REGRESSION(75137): directly composited images are double-drawn sometimes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Chris Marrin
URL: http://trac.webkit.org/export/83947/t...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-04-14 22:28 PDT by James Robinson
Modified: 2011-04-25 17:29 PDT (History)
3 users (show)

See Also:


Attachments
Patch (1.91 KB, patch)
2011-04-25 15:31 PDT, Chris Marrin
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Robinson 2011-04-14 22:28:24 PDT
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.
Comment 1 Simon Fraser (smfr) 2011-04-14 22:35:27 PDT
Would be good to know when this regressed.
Comment 2 Simon Fraser (smfr) 2011-04-14 22:35:58 PDT
<rdar://problem/9289398>
Comment 3 James Robinson 2011-04-14 22:52:11 PDT
bisect-builds says http://trac.webkit.org/log/trunk/?rev=75294&stop_rev=74229 - sadly large range.
Comment 4 James Robinson 2011-04-14 23:36:57 PDT
Tighter range (using chromium continuous builds): http://trac.webkit.org/log/trunk/?rev=75164&stop_rev=74761.  Perhaps http://trac.webkit.org/changeset/75137 ?
Comment 5 Simon Fraser (smfr) 2011-04-15 08:30:51 PDT
That's possible.
Comment 6 Simon Fraser (smfr) 2011-04-15 10:51:19 PDT
I narrowed this down to between r75123 and r75154.
Comment 7 James Robinson 2011-04-15 13:56:47 PDT
Confirmed that reverting 75137 locally fixes the bug.
Comment 8 Chris Marrin 2011-04-25 15:31:33 PDT
Created attachment 90959 [details]
Patch
Comment 9 James Robinson 2011-04-25 15:45:37 PDT
Comment on attachment 90959 [details]
Patch

It should be possible to construct a pixel test for this, right?
Comment 10 Chris Marrin 2011-04-25 16:26:25 PDT
(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.
Comment 11 Chris Marrin 2011-04-25 17:24:58 PDT
Committed r84856: <http://trac.webkit.org/changeset/84856>
Comment 12 Chris Marrin 2011-04-25 17:29:38 PDT
(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.