Snapshots of various layers bugging out. Skia producing incorrect SKPs?
Reported by
da...@davidjfox.com,
Apr 28 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2716.0 Safari/537.36 Steps to reproduce the problem: 1. Go to the timeline tab in devtools and set it up to capture "Paint" events 2. Record the html file attached to this bug report 3. Stop recording when the page is done loading and view the Layer section in each of the frames (you may have to record a couple refreshes as well since the page loads so quickly) 4. See the bugged output What is the expected behavior? What went wrong? The paints of in the layer view should result in expected.jpg not bugged.jpg You can see in bugged-layer.jpg that a completely white layer has been created which eventually overlaps other layers... thus creating the bugged output Did this work before? Yes Chrome version: 52.0.2716.0 Channel: canary OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 Probably a similar problem to https://crbug.com/587315 This issue goes away if you don't force the button to have its own layer (remove u-forceLayer in the html)
,
Apr 28 2016
I am unable to recreate this bug, can you give more details and/or video on what happens? Thanks!
,
Apr 28 2016
Don't think a video would help you very much, but I can send you the traces so you can import them yourself. What version of chrome and windows are you using? I'd like to check if this is just an issue with my computer. Bugged Trace: https://drive.google.com/file/d/0Bxc8EXysx0ykWEg1d1BjZ0FCU2s/view?usp=sharing Expected Trace: https://drive.google.com/file/d/0Bxc8EXysx0ykdDI2VTFXR0N3TjA/view?usp=sharing
,
Apr 28 2016
Also by not being able to recreate the bug, I take it you mean you always get the expected.jpg result?
,
Apr 29 2016
Thank you for providing more feedback. Adding requester "allada@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 2 2016
Aaaah, yes I was able to reproduce. Sending to caseq@ for further handling.
,
Jun 8 2016
I can repro in chrome://tracing also, so probably more general than devtools. What seems to be going on is we have 4 layers, but only the topmost one is shown/accessible in the cc::DisplayItemList view. The cc::LayerTreeHostImpl view does show a correctly composited result. It also allows access to all layer recordings (possible workaround): click on one of the 4 cc::PictureLayerImpls on the left list, then click on the "Snapshot of cc::DisplayItemList..." link. @pdr are you the right owner for this?
,
Jun 8 2016
,
Jun 8 2016
,
Jun 8 2016
,
Jun 8 2016
,
Jun 8 2016
,
Jun 8 2016
I'd be surprised if 15996c4ff96f68c898a5582078c9728420341633 caused changes in display list topology. Easy enough to test.
,
Jun 8 2016
Exactly what I'm doing now; just logging my progress on the bug. ;)
,
Jun 8 2016
I meant I was going to check myself :) Reverting doesn't fix the problem for me. Are you bisecting using devtools or chrome://tracing? I'm testing the latter.
,
Jun 8 2016
DevTools; the range above is what bisect-builds.py lead me to.
,
Jun 8 2016
Got you. I can repro the regression (from 15996c4ff96f68c898a5582078c9728420341633) in devtools - but not in chrome://tracing. So my c#7 is likely a different issue (if any). Back at me.
,
Jun 8 2016
And it's pretty consistent for me: at 15996c4ff96f68c898a5582078c9728420341633^ I get the full page (albeit discoloured, but I gather you later fixed that), and at 15996c4ff96f68c898a5582078c9728420341633 I only get the button (again, discoloured). My repro steps: 1. chrome path/to/test.html 2. right-click, inspect, timeline, record 3. press refresh twice (about 1s apart) 4. look at the last frame, and choose the "Layers" tab
,
Jun 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cdb916fa992641446848743640537454be31a56a commit cdb916fa992641446848743640537454be31a56a Author: fmalita <fmalita@chromium.org> Date: Fri Jun 10 05:09:55 2016 DevTools: clear layers using transparent color The default layer backing is transparent. Clearing with anything else can interfere with compositing later. Use transparent color instead of opaque white when clearing layers for partial playback. R=caseq@chromium.org,jbroman@chromium.org BUG= 607720 Review-Url: https://codereview.chromium.org/2044643006 Cr-Commit-Position: refs/heads/master@{#399106} [modify] https://crrev.com/cdb916fa992641446848743640537454be31a56a/third_party/WebKit/Source/platform/graphics/ReplayingCanvas.cpp
,
Jun 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cdb916fa992641446848743640537454be31a56a commit cdb916fa992641446848743640537454be31a56a Author: fmalita <fmalita@chromium.org> Date: Fri Jun 10 05:09:55 2016 DevTools: clear layers using transparent color The default layer backing is transparent. Clearing with anything else can interfere with compositing later. Use transparent color instead of opaque white when clearing layers for partial playback. R=caseq@chromium.org,jbroman@chromium.org BUG= 607720 Review-Url: https://codereview.chromium.org/2044643006 Cr-Commit-Position: refs/heads/master@{#399106} [modify] https://crrev.com/cdb916fa992641446848743640537454be31a56a/third_party/WebKit/Source/platform/graphics/ReplayingCanvas.cpp
,
Jun 15 2016
,
Feb 2 2017
|
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by da...@davidjfox.com
, Apr 28 2016