paint_chunks_to_cc_layer.cc error |
|||||||||
Issue descriptionFound this while investigating issue 886997 . Not sure whether this is the root cause or a side issue. On Chrome on Linux, open up reddit.com. Scroll down, click on a post with a video or gif? Receive errors: [1:1:1005/171303.402438:ERROR:paint_chunks_to_cc_layer.cc(335)] Error: Chunk has a clip that escaped its layer's or effect's clip. target_clip: root 0x321595a46610 {"localTransformSpace":"0x321595a7d1f0","rect":"InfiniteIntRect"} OverflowClip (LayoutView #document) 0x321595a46710 {"parent":"0x321595a46610","localTransformSpace":"0x321595a7c4f0","rect":"0,0 1282x1074","rectExcludingOverlayScrollbars":"0,0 1282x1074"} current_clip_: root 0x321595a46610 {"localTransformSpace":"0x321595a7d1f0","rect":"InfiniteIntRect"} OverflowClip (LayoutView #document) 0x321595a46710 {"parent":"0x321595a46610","localTransformSpace":"0x321595a7c4f0","rect":"0,0 1282x1074","rectExcludingOverlayScrollbars":"0,0 1282x1074"} OverflowClip (LayoutBlockFlow DIV id='overlayScrollContainer' class='lli3cx-7 doNtvE') 0x321595f03010 {"parent":"0x321595a46710","localTransformSpace":"0x321595a84210","rect":"0,0 1267x1074","rectExcludingOverlayScrollbars":"0,0 1267x1074"}
,
Oct 8
Also making this a P1 given the issues that it might be causing on Reddit.
,
Oct 8
It looks like that we encounter the fundamental compositing bug of SPv1 which is the reason that the error message is not a DCHECK. I just bisected bug 886997 to a range that is not related to the error message, so I'm marking this bug WontFix. The error message can only be fixed in slimming paint v2.
,
Oct 12
This looks the root cause of the bug 886997 . (The dropbox bug that I bisected was really unrelated and has been fixed.)
,
Oct 12
I also see another error message: [1:8:1012/102114.907196:ERROR:render_surface_impl.cc(648)] Not implemented reached in void cc::RenderSurfaceImpl::TileMaskLayer(viz::RenderPass *, viz::SharedQuadState *, const gfx::Rect &) Is it another culprit?
,
Oct 12
The above error message shows only if I use --show-composited-layer-borders. Maybe not relevant.
,
Oct 12
The paint_chunks_to_cc_layer.cc error message is about a chunk containing the outline of "LayoutBlockFlow DIV id='overlayScrollContainer' class='l2w6h7-5 kFUlrp'" painted on the foreground layer of the scrollable div.
The part of layer tree is like (all belonging to the same div):
Container layer
Scrolling layer
Scrolling Contents layer
Foreground layer
The foreground layer has the scrolling contents property tree state, while the outline chunk has the container property tree state. This looks incorrect to me.
,
Oct 12
I can reproduce the error message with the following test case: <!DOCTYPE html> <div id="container" style="width: 200px; height: 200px; overflow: scroll; outline: 10px solid yellow; will-change: transform"> <div id="content" style="width: 2000px; height: 2000px">CONTENT</div> <div id="negz" style="position: absolute; top: 0; left: 0; width: 100px; height: 100px; will-change: transform; z-index: -1; background-color: red"></div> </div> It seems that the foreground layer has wrong paint property state. However, I'm a bit confused by the purpose of foreground layer: 1. It has kGraphicsLayerPaintForeground and kGraphicsLayerPaintOverflowContents paint phases. Why the latter? 2. The foreground and the scrolling contents are in different property tree states, so is it expected to invalidate raster (which we are doing now) on composited scroll? 3. Both the scrolling contents layer and the foreground layer have kGraphicsLayerPaintOverflowContents. Won't this paint the overflow contents twice? (Looked at the code, and overflow contents seem different from scrolling contents, but controls should_paint_neg_z_order_list. However, when we composite the container, it seems that the negative z-order descendants are also composited and painted separately.) 4. If there is no foreground layer, but scrolling contents layer, the scrolling contents layer will paint the foreground (outline). Is this correct? The outline chunk will still escape the clip state of the layer and cause the error message and raster invalidation during composited scrolling.
,
Oct 12
Never mind my questions. I found I mixed kGraphicsLayerPaintOverflowContents and kGraphicsLayerPaintScrollingContents. Outline is of kGraphicsLayerPaintOverflowContents because it is not clip by the overflow clip. The scrolling contents layer also needs it to avoid the overflow clip (which might be unnecessary now).
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/89879ac0cab5651b77aa9dd512f9544dc7454b63 commit 89879ac0cab5651b77aa9dd512f9544dc7454b63 Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Fri Oct 12 23:28:57 2018 [PE] Don't paint outline on foreground layer "Background" of the foreground layer: A foreground layer is created for a composited scrolling element with composited negative-z-order descendants. It's actually another scrolling contents layer which paints non-composited normal and positive-z-order descendants, while the original scrolling contents layer paints the scrolling background and descendants below the composited negative-z-order layer. The foreground layer and the scrolling contents layer both scroll and use the contents property tree state. Previously we mistakenly painted outline on the foreground layer (and on the main layer). The bug had existed before SPv175 when we could see an extra outline scrolling with the contents. In SPv175, we saw an error message saying that the outline's chunk's clip state escaped the layer's clip state, and the foreground layer was fully raster invalidated on each scroll. Not sure how the clip-escaping broke rendering. Bug: 886997 , 892855 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I9ad7db2baa526f085676f13c429460c4ff46322c Reviewed-on: https://chromium-review.googlesource.com/c/1278990 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#599412} [add] https://crrev.com/89879ac0cab5651b77aa9dd512f9544dc7454b63/third_party/WebKit/LayoutTests/flag-specific/enable-slimming-paint-v2/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/89879ac0cab5651b77aa9dd512f9544dc7454b63/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.html [add] https://crrev.com/89879ac0cab5651b77aa9dd512f9544dc7454b63/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/89879ac0cab5651b77aa9dd512f9544dc7454b63/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer.html [modify] https://crrev.com/89879ac0cab5651b77aa9dd512f9544dc7454b63/third_party/blink/renderer/core/paint/paint_layer_painter.cc
,
Oct 13
,
Oct 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/728442c62bcd804b075b03e13e824fe1bd3bab37 commit 728442c62bcd804b075b03e13e824fe1bd3bab37 Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Mon Oct 15 18:01:57 2018 [PE] Don't paint outline on foreground layer "Background" of the foreground layer: A foreground layer is created for a composited scrolling element with composited negative-z-order descendants. It's actually another scrolling contents layer which paints non-composited normal and positive-z-order descendants, while the original scrolling contents layer paints the scrolling background and descendants below the composited negative-z-order layer. The foreground layer and the scrolling contents layer both scroll and use the contents property tree state. Previously we mistakenly painted outline on the foreground layer (and on the main layer). The bug had existed before SPv175 when we could see an extra outline scrolling with the contents. In SPv175, we saw an error message saying that the outline's chunk's clip state escaped the layer's clip state, and the foreground layer was fully raster invalidated on each scroll. Not sure how the clip-escaping broke rendering. TBR=wangxianzhu@chromium.org (cherry picked from commit 89879ac0cab5651b77aa9dd512f9544dc7454b63) Bug: 886997 , 892855 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I9ad7db2baa526f085676f13c429460c4ff46322c Reviewed-on: https://chromium-review.googlesource.com/c/1278990 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#599412} Reviewed-on: https://chromium-review.googlesource.com/c/1280929 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#1000} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [add] https://crrev.com/728442c62bcd804b075b03e13e824fe1bd3bab37/third_party/WebKit/LayoutTests/flag-specific/enable-slimming-paint-v2/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/728442c62bcd804b075b03e13e824fe1bd3bab37/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.html [add] https://crrev.com/728442c62bcd804b075b03e13e824fe1bd3bab37/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/728442c62bcd804b075b03e13e824fe1bd3bab37/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer.html [modify] https://crrev.com/728442c62bcd804b075b03e13e824fe1bd3bab37/third_party/blink/renderer/core/paint/paint_layer_painter.cc
,
Oct 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/728442c62bcd804b075b03e13e824fe1bd3bab37 Commit: 728442c62bcd804b075b03e13e824fe1bd3bab37 Author: wangxianzhu@chromium.org Commiter: wangxianzhu@chromium.org Date: 2018-10-15 18:01:57 +0000 UTC [PE] Don't paint outline on foreground layer "Background" of the foreground layer: A foreground layer is created for a composited scrolling element with composited negative-z-order descendants. It's actually another scrolling contents layer which paints non-composited normal and positive-z-order descendants, while the original scrolling contents layer paints the scrolling background and descendants below the composited negative-z-order layer. The foreground layer and the scrolling contents layer both scroll and use the contents property tree state. Previously we mistakenly painted outline on the foreground layer (and on the main layer). The bug had existed before SPv175 when we could see an extra outline scrolling with the contents. In SPv175, we saw an error message saying that the outline's chunk's clip state escaped the layer's clip state, and the foreground layer was fully raster invalidated on each scroll. Not sure how the clip-escaping broke rendering. TBR=wangxianzhu@chromium.org (cherry picked from commit 89879ac0cab5651b77aa9dd512f9544dc7454b63) Bug: 886997 , 892855 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I9ad7db2baa526f085676f13c429460c4ff46322c Reviewed-on: https://chromium-review.googlesource.com/c/1278990 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#599412} Reviewed-on: https://chromium-review.googlesource.com/c/1280929 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#1000} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bcf1d86b2994e1376ffd5559708012768e394e1a commit bcf1d86b2994e1376ffd5559708012768e394e1a Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Tue Oct 16 15:56:03 2018 [PE] Don't paint outline on foreground layer "Background" of the foreground layer: A foreground layer is created for a composited scrolling element with composited negative-z-order descendants. It's actually another scrolling contents layer which paints non-composited normal and positive-z-order descendants, while the original scrolling contents layer paints the scrolling background and descendants below the composited negative-z-order layer. The foreground layer and the scrolling contents layer both scroll and use the contents property tree state. Previously we mistakenly painted outline on the foreground layer (and on the main layer). The bug had existed before SPv175 when we could see an extra outline scrolling with the contents. In SPv175, we saw an error message saying that the outline's chunk's clip state escaped the layer's clip state, and the foreground layer was fully raster invalidated on each scroll. Not sure how the clip-escaping broke rendering. TBR=wangxianzhu@chromium.org (cherry picked from commit 89879ac0cab5651b77aa9dd512f9544dc7454b63) Bug: 886997 , 892855 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I9ad7db2baa526f085676f13c429460c4ff46322c Reviewed-on: https://chromium-review.googlesource.com/c/1278990 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#599412} Reviewed-on: https://chromium-review.googlesource.com/c/1283477 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/branch-heads/3578@{#40} Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034} [add] https://crrev.com/bcf1d86b2994e1376ffd5559708012768e394e1a/third_party/WebKit/LayoutTests/flag-specific/enable-slimming-paint-v2/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/bcf1d86b2994e1376ffd5559708012768e394e1a/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.html [add] https://crrev.com/bcf1d86b2994e1376ffd5559708012768e394e1a/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer-expected.txt [add] https://crrev.com/bcf1d86b2994e1376ffd5559708012768e394e1a/third_party/WebKit/LayoutTests/paint/invalidation/compositing/should-not-paint-outline-on-foreground-layer.html [modify] https://crrev.com/bcf1d86b2994e1376ffd5559708012768e394e1a/third_party/blink/renderer/core/paint/paint_layer_painter.cc
,
Oct 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bcf1d86b2994e1376ffd5559708012768e394e1a Commit: bcf1d86b2994e1376ffd5559708012768e394e1a Author: wangxianzhu@chromium.org Commiter: wangxianzhu@chromium.org Date: 2018-10-16 15:56:03 +0000 UTC [PE] Don't paint outline on foreground layer "Background" of the foreground layer: A foreground layer is created for a composited scrolling element with composited negative-z-order descendants. It's actually another scrolling contents layer which paints non-composited normal and positive-z-order descendants, while the original scrolling contents layer paints the scrolling background and descendants below the composited negative-z-order layer. The foreground layer and the scrolling contents layer both scroll and use the contents property tree state. Previously we mistakenly painted outline on the foreground layer (and on the main layer). The bug had existed before SPv175 when we could see an extra outline scrolling with the contents. In SPv175, we saw an error message saying that the outline's chunk's clip state escaped the layer's clip state, and the foreground layer was fully raster invalidated on each scroll. Not sure how the clip-escaping broke rendering. TBR=wangxianzhu@chromium.org (cherry picked from commit 89879ac0cab5651b77aa9dd512f9544dc7454b63) Bug: 886997 , 892855 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I9ad7db2baa526f085676f13c429460c4ff46322c Reviewed-on: https://chromium-review.googlesource.com/c/1278990 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#599412} Reviewed-on: https://chromium-review.googlesource.com/c/1283477 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/branch-heads/3578@{#40} Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034} |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by schenney@chromium.org
, Oct 8Status: Assigned (was: Untriaged)