fast/css/all-shorthand-first-letter.html fails with spv2 and layer lists |
||||
Issue descriptionThis test is failing due to a very small opacity difference: fast/css/all-shorthand-first-letter.html https://storage.googleapis.com/chromium-layout-test-archives/linux_layout_tests_slimming_paint_v2/224/layout-test-results/results.html
,
Sep 23 2016
Currently, we're only creating a root render surface when using PaintArtifactCompositor. In cc, render surface determination is still happening in PropertyTreeBuilder, so gets skipped in slimming-paint-v2 mode. So only the root effect node gets a surface (since PaintArtifactCompositor sets only that node's has_render_surface bit to true). And this means that effects get applied to each layer separately. The plan is to move render surface determination out of PropertyTreeBuilder over to the compositor thread (and then it won't get skipped in spv2 mode).
,
Sep 23 2016
Thanks! Is there a bug I could block this on?
,
Sep 23 2016
,
Sep 23 2016
,
Dec 2 2016
This was fixed by Tien-ren's recent effect tree work. Updating expectation in https://codereview.chromium.org/2550793002 |
||||
►
Sign in to add a comment |
||||
Comment 1 by pdr@chromium.org
, Sep 23 2016Here's a minimized repro of the bug, just open with --enable-slimming-paint-v2: <!DOCTYPE html> <style> #elm { overflow:hidden; width:100px; opacity:0.6; background:blue; } #elm::first-letter { background: blue; } </style> <div id="elm">P</div> I confirmed the paint artifact compositor is sending cc correct-looking trees. I think what is happening is that we have two chunks associated with an opacity effect and we want them to draw into the same render surface, but a clip forces them into two surfaces which ends up double-drawing the background color.3.9 KB
3.9 KB View Download