Issue metadata
Sign in to add a comment
|
Paint invalidation does not pixel-snap when crossing paintingRoot boundaries
Reported by
jshan...@etouch.net,
Mar 14 2016
|
|||||||||||||||||||||||
Issue descriptionChrome Version: 51.0.2677.0 (Official Build) 1f6eed8e362f458537e8a95c1df27e38cdc9c334-refs/heads/master@{#380902}-32/64 bit OS: Windows(Win 7-Aero enabled) URL: http://www.rediff.com/movies/column/arbaaz-malaika-arjun-kapoor-and-raakhee-the-week-in-the-movies/20160314.htm Steps: 1. Launch Chrome and navigate to above URL. 2. Move the mouse right-left over the image seen under 'Monday' and observe Actual: Unwanted white lines is seen on moving the mouse right-left over the image. Expected: No such lines should be seen on moving the mouse right-left over the image. This is a regression issue broken in M-51, below is bisect info. Good build: 51.0.2671.0 Bad build: 51.0.2672.0 Narrow bisect: https://chromium.googlesource.com/chromium/src/+log/3436bb5299b3c8becec4c7033c25f3f8c70c5692..f2a796fea172c30e8ca69d59f36120c53c8b2acd?pretty=fuller&n=100 Suspecting: r379778 ? Please help to reassign if your change is not the cause. Note: This issue is not seen on Mac OS.
,
Mar 14 2016
P.S - Issue is not observed on Linux OS as well.
,
Mar 14 2016
Thanks for reporting. I reproduced it in linux using ToT. Let me fix.
,
Mar 14 2016
,
Mar 14 2016
attach the minimal case. Invalidation of div border has off-by-1px bug.
,
Mar 14 2016
+ chrishtr, leviw #5 - div inside iframe has invalidation issue. dirty region of div border is incorrectly calculated by off-by-1px. Do you have some clue?
,
Mar 14 2016
,
Mar 15 2016
I will look into it.
,
Mar 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5fd393f0a9d84a4a6b83c781f019c9637143ad29 commit 5fd393f0a9d84a4a6b83c781f019c9637143ad29 Author: dongseong.hwang <dongseong.hwang@intel.com> Date: Tue Mar 15 21:13:38 2016 compositor: Disable partial raster by default. After enabling it, BUG= 594516 is regressed. Before fixing it, disable it by default. BUG= 492754 , 594516 Review URL: https://codereview.chromium.org/1801093003 Cr-Commit-Position: refs/heads/master@{#381316} [modify] https://crrev.com/5fd393f0a9d84a4a6b83c781f019c9637143ad29/content/browser/gpu/compositor_util.cc
,
Mar 17 2016
Removing releaseblock as the feature was reverted.
,
Mar 18 2016
I can't reproduce this one at ToT with partial raster on Linux. Maybe partial raster is not working on my machine.
,
Mar 18 2016
If you can repro still, please send it back to me again. Otherwise please close. I loaded the reduced testcase and could not repro the kind of problem described in the video in #0. I was able to reproduce crbug.com/594962 however, so I think partial raster works ok on my machine.
,
Mar 18 2016
Rechecked this issue on Chrome Canary version:51.0.2682.0 and fix is working as intended.
,
Mar 18 2016
,
Mar 18 2016
I can still reproduce it. You have to revert #9, which disables partial raster. It's reproducing step. 1. git revert 5fd393f0a9d84a4a6b83c781f019c9637143ad29 2. download two files at #5 3. ./out/Release/chrome <download folder>/border_invalidation_incorrect.html 4. hover mouse on the red box
,
Mar 18 2016
I can reproduce on 51.0.2679.0 / dev on my Linux box, but cannot reproduce with a ToT Chromium with partial raster turned back on. Neither can I reproduce on OS X / Retina ToT Chromium. Hmm.
,
Mar 18 2016
Eric also can't repro at ToT. Are you sure it repros at ToT?
,
Mar 18 2016
,
Mar 21 2016
#16- strange. I can reproduce on Ubuntu using ToT, whose latest commit is commit 8d6342181e81b6dd0988283b785d0724c686f096 Author: reveman <reveman@chromium.org> Date: Fri Mar 18 09:30:46 2016 -0700 See the video clip. Did you revert the commit 5fd393f0a9d84a4a6b83c781f019c9637143ad29 ? If nobody can reproduce, let me fix it. Do you have some clues where is root cause?
,
Mar 21 2016
Now I can reproduce it. It seems it depends on the size of the window in some way.
,
Mar 21 2016
#20 - yes, document scroll is needed to reproduce. It's why I add many <p> in the test, but may not enough for you. You might have very high resolution monitor.
,
Mar 21 2016
The problem is I think a mismatch between paint invalidation and paint in cases that involve subpixel offsets. This bug only reproduces if the body of the root frame has an odd width. The margin is auto in the x direction, content ins centered. Since the body has an odd width, the element with id "wrapper" has a frame rect that has a 0.5 subpixel offset; the same goes for the "mars" element in the frame. The paint invalidation code does not do any pixel snapping when mapping to the paint invalidation container, which in this case is the root LayoutView of the main frame. I think the paint code is doing pixel snapping. I think the solution will be to match those. Digging deeper to confirm now.
,
Mar 22 2016
I have a fix, just cleaning it up. Need to make paint invalidation pixel-snap when crossing transformed or frame boundaries.
,
Mar 22 2016
,
Mar 22 2016
,
Mar 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4e57e854bd3a3e47c4aa18ce934d838e4eed4030 commit 4e57e854bd3a3e47c4aa18ce934d838e4eed4030 Author: chrishtr <chrishtr@chromium.org> Date: Wed Mar 23 02:17:56 2016 Pass nullptr for paintInvalidationState if it can't be used to map geometry. If it can't be used for the current object, it can't be used for an ancestor. Therefore, after it returning false for canMapToAncestor(), pass nullptr fur further recursions up the layout tree. Furthermore, using it for an ancestor is invalid because a PaintInvalidationState object is bound to a single LayoutObject. Also adds PaintInvalidationState early-outing to LayoutView. BUG= 594516 Review URL: https://codereview.chromium.org/1818963003 Cr-Commit-Position: refs/heads/master@{#382772} [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/LayoutBox.cpp [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/LayoutInline.cpp [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/LayoutView.cpp [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/svg/LayoutSVGInlineText.cpp [modify] https://crrev.com/4e57e854bd3a3e47c4aa18ce934d838e4eed4030/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.cpp
,
Mar 23 2016
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b4e779badf599485ed255b8a81937a7c1324368a commit b4e779badf599485ed255b8a81937a7c1324368a Author: chrishtr <chrishtr@chromium.org> Date: Tue Mar 29 19:29:04 2016 Round visual rects when crossing frame boundaries. Visual rects must match painted output, and frames are painted at rounded-int offsets. BUG= 594516 Review URL: https://codereview.chromium.org/1834263002 Cr-Commit-Position: refs/heads/master@{#383792} [add] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/LayoutTests/paint/invalidation/iframe-rounding-expected.txt [add] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/LayoutTests/paint/invalidation/iframe-rounding.html [modify] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/Source/core/layout/LayoutObjectTest.cpp [modify] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/Source/core/layout/LayoutView.cpp [modify] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp [modify] https://crrev.com/b4e779badf599485ed255b8a81937a7c1324368a/third_party/WebKit/Source/core/paint/PartPainter.cpp
,
Mar 29 2016
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0aab1b730f57ecada9292ef04a1a324db7b658f9 commit 0aab1b730f57ecada9292ef04a1a324db7b658f9 Author: chrishtr <chrishtr@chromium.org> Date: Tue Mar 29 21:43:08 2016 Mark one test as NeedsRebaseline after fix to referenced bug. fast/repaint/repaint-during-scroll-with-zoom.html TBR=wangxianzhu@chromium.org BUG= 594516 Review URL: https://codereview.chromium.org/1840183002 Cr-Commit-Position: refs/heads/master@{#383837} [modify] https://crrev.com/0aab1b730f57ecada9292ef04a1a324db7b658f9/third_party/WebKit/LayoutTests/TestExpectations
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034 commit ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034 Author: Rebaseline Bot <blink-rebaseline-bot@chromium.org> Date: Tue Mar 29 23:29:18 2016 Auto-rebaseline for r383837 https://chromium.googlesource.com/chromium/src/+/0aab1b730 BUG= 594516 TBR=chrishtr@chromium.org Review URL: https://codereview.chromium.org/1838383003 . Cr-Commit-Position: refs/heads/master@{#383861} [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/TestExpectations [add] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/android/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/linux/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/mac/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/win/fast/repaint/repaint-during-scroll-with-zoom-expected.txt
,
Mar 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034 commit ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034 Author: Rebaseline Bot <blink-rebaseline-bot@chromium.org> Date: Tue Mar 29 23:29:18 2016 Auto-rebaseline for r383837 https://chromium.googlesource.com/chromium/src/+/0aab1b730 BUG= 594516 TBR=chrishtr@chromium.org Review URL: https://codereview.chromium.org/1838383003 . Cr-Commit-Position: refs/heads/master@{#383861} [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/TestExpectations [add] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/android/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/linux/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/mac/fast/repaint/repaint-during-scroll-with-zoom-expected.txt [modify] https://crrev.com/ed3a2b5ad56d2d5466003e38fc1e61c6e36a7034/third_party/WebKit/LayoutTests/platform/win/fast/repaint/repaint-during-scroll-with-zoom-expected.txt
,
Mar 30 2016
The CL caused mismatch of fast-path and slow-path rects. 147 layout tests crash locally with ASSERT_SAME_RESULT_SLOW_AND_FAST_PATH enabled. They will show up in try results for https://codereview.chromium.org/1838853007 Patch Set 1. I'm looking into it.
,
Mar 30 2016
There seems no feasible way to let slow-path (bottom-up rects) and fast-path (top-down paint-offset) produce the same result crossing frames. Will change the rect comparison method to tolerate the differences.
,
Mar 30 2016
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Mar 14 2016