Issue metadata
Sign in to add a comment
|
[Blink] Document background paints in wrong position in RLS with composited scrolling |
||||||||||||||||||||||
Issue descriptionChrome Version: ToT What steps will reproduce the problem? (1) Launch chrome with --enable-prefer-compositing-to-lcd-text --root-layer-scrolls (2) Open https://output.jsbin.com/xodohul/quiet (3) Scroll around What is the expected result? The page flicker every 500ms to repaint background, but the background should stay still. What happens instead? Background paints with different layout as page scrolls. This is a new regression from https://codereview.chromium.org/2655023003 I tried to remove the newly added ScrollRecorder in ViewPainter, background no longer seemed to move around, but will have wrong (shifted) paint bounds.
,
Jul 14 2017
I don't see any difference with / without the flags on in Canary. Could you be more specific on the unexpected behavior? That patch was to paint the local/scroll attachments into scrolling contents layer in RLS. Have you tried to paint them into graphics layer to see whether the bug is still there?
,
Jul 14 2017
,
Jul 17 2017
Yes I can repro on ToT as of today. The old code path of painting into main graphics layer is still okay. The bug only happens when the document background is painted into scrolling contents layer. It may be easier to observe without constantly refreshing. Try this repro: https://output.jsbin.com/gizimo/quiet . It only repaints when you click anywhere on the page. In the beginning you can see the background image correctly aligned to the top-left corner. After scrolling some distance, click anywhere on the page, you'll see background image jumps to a different location. Now scroll back to the top, you'll observe the background image is no longer aligned to the top-left corner.
,
Jul 18 2017
Thanks for the updated repro! It seems that whenever you click "after" you scroll the page, the background will be offset by certain amount proportional to the scroll offset. Therefore after seeing the bug, if we scroll back to the top and click again, the background will be correctly located as the scroll offset is now zero.
,
Jul 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0741da08477eec28b601c8517428127c6714f216 commit 0741da08477eec28b601c8517428127c6714f216 Author: Yi Gu <yigu@chromium.org> Date: Tue Jul 25 18:34:13 2017 Fix the bug that document background paints in wrong position in RLS With root layer scrolling local/scroll background is painted into scrolling contents layer instead of graphics layer. But the scrolled content offset has not been taken into account when computing the offset which is used for shifting the background. Bug: 742555 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I65bd6579c77482df803235bd5599b17ee2baeffb Reviewed-on: https://chromium-review.googlesource.com/579949 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Tien-Ren Chen <trchen@chromium.org> Commit-Queue: Yi Gu <yigu@chromium.org> Cr-Commit-Position: refs/heads/master@{#489383} [add] https://crrev.com/0741da08477eec28b601c8517428127c6714f216/third_party/WebKit/LayoutTests/paint/overflow/background-paint-into-scrolling-contents-layer-with-root-layer-scrolls-offset-expected.html [add] https://crrev.com/0741da08477eec28b601c8517428127c6714f216/third_party/WebKit/LayoutTests/paint/overflow/background-paint-into-scrolling-contents-layer-with-root-layer-scrolls-offset.html [modify] https://crrev.com/0741da08477eec28b601c8517428127c6714f216/third_party/WebKit/Source/core/paint/ViewPainter.cpp
,
Jul 25 2017
,
Jul 28 2017
The NextAction date has arrived: 2017-07-28 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by chrishtr@chromium.org
, Jul 13 2017