Issue metadata
Sign in to add a comment
|
Painting certain rectangles fails for reddit.com overlay layer
Reported by
kyle.new...@reddit.com,
Sep 19
|
||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Navigate to reddit.com (make sure it's the redesign) 2. Scroll down for a while so there are at least 600 posts (not sure exact number...lots of posts, in any subreddit) 3. click on a post with a video embed (youtube, vimeo) to open lightbox 4. click play on the video 5. chunks of the topmost page layer disappear What is the expected behavior? The entire page should still be visible when interacting with any part of it. What went wrong? Not sure - looks like some issues painting parts of the page. After hovering on other interactive elements on the page, the missing chunks will flash in and out. After navigating to a different tab and then back, the entire page is visible. This problem also happens occasionally on other types of post lightboxes, not just those with embeds, but is easiest to reproduce with embeds. Looks somewhat related to GPU process memory usage maybe? Also fairly easy to reproduce on subreddits with a lot of animation like r/partyparrot. Did this work before? N/A Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.12.6 Flash Version: I believe it's got something to do with the fact that we're using layer compositing - `will-change: transform` on the overlayScrollContainer div to create a new layer with all of the comments to optimize scrolling speed. I've heard removing this property gets rid of the problem, but the scrolling performance is dramatically impacted. We didn't start noticing this issue until a couple of versions ago, so it might be a regression. With paint rectangles turned on, it looks like the missing chunks are one or more of those rectangles, so I figure it's probably related to the painting logic. Please let me know how we can help, debug, or mitigate on our end, it's been an issue for the past month or two that none of us here can figure out, and are very eager to get it fixed. If there's any browser event we can listen for when this happens, that would also be very helpful so we can monitor potential solutions on our end. maybe related? https://productforums.google.com/forum/#!topic/chrome/jUbPJZ4CFu0 https://productforums.google.com/forum/#!topic/chrome/VXoAbUygYdM
,
Sep 26
Mac triage: flagging for TE help.
,
Sep 26
+cc ccameron@ also :)
,
Sep 26
Note that in the screenshots, composited layer borders are showing, which has the effect of disabling Mac Overlays (that is, forces us to use the GL renderer). So we know that this isn't related to Mac Overlays. This strikes me as a paint bug. ->schenney to route
,
Sep 27
kyle.newkirk@ Thanks for the issue. Tested this issue on Mac OS 10.13.3 on the reported version 69.0.3497.100 and the latest Canary 71.0.3562.0 and unable to reproduce the issue by following the below steps. 1. Launched Chrome and navigated to http://reddit.com/. 2. Scrolled through the page and clicked on a post which has a video embed. 3. Played the video and cannot observe any chunks of topmost page disappear. Attached is the screen cast for reference. As this issue is not reproducible at TE-end, removing the 'Needs-TestConfirmation' label. Thanks..
,
Sep 27
Could you please include the output from navigating to chrome://gpu? Does modifying any of the GPU related flags in chrome://flags make a difference? What kind of machine is this failing on (Retina, iMac, etc)? Does it occur on multiple devices? Finally, could you install Chrome Canary (it can live alongside Stable or Beta) and see if the issue still appears there? I agree with the assessment that it seems to be discarding memory for tiles, But it may also be some kind of issue with texture memory management on the GPU. We've seen issues on Android with missing content but that looks different to this.
,
Sep 28
Hi Chrome team, thanks for responding! In your reproduction video, it looks like you actually clicked on the username of the poster, which took you to the profile page, not the lightbox. If you click on the post title, or any of the whitespace on the post, the lightbox should open. I've attached a video reproducing the issue - you'll have to take my word for it that there were a few hundred posts above it, and the GPU process memory was around 800 MB. It is hard to reproduce, and I'm very sorry about that, it's been driving our team nuts trying to repro and figure it out. > Could you please include the output from navigating to chrome://gpu? Attached - this was taken right after the bug occurred on a different tab. > Does modifying any of the GPU related flags in chrome://flags make a difference? I've only experimented with a couple, but none seemed to make a difference, and it was also hard to tell as it's very tough to reliably repro. The "enable hardware acceleration" flag in advanced settings didn't seem to change things. Let me know if there are specific ones I should try out. > What kind of machine is this failing on (Retina, iMac, etc)? Does it occur on multiple devices? We've gotten reports of it failing on both Mac and Windows, and multiple different kinds of monitors. Haven't gotten reports of it happening on mobile? (although the site isn't very responsive atm :-( ) > Finally, could you install Chrome Canary (it can live alongside Stable or Beta) and see if the issue still appears there? I have it and have been trying to reproduce and haven't been able to so far for the last 15 minutes or so, so it may have been resolved? I can't tell for sure though - will continue trying. FWIW, the GPU process memory is considerably less - >200 MB so far, which seems like it's a contributing factor. Thanks again for your help, and let me know if you need more info.
,
Sep 28
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1
Given the large GPU memory consumption, and differences there between Canary and Stable, and the nature of missing rectangles, this seems most likely a GPU issue with raster or tiles. I've upped the priority until we can manage to reproduce somehow. Also added Windows based on most recent comments. Could be invalidation for root layer scrolling, somehow, but then I would expect to have seen way more of it.
,
Oct 5
This sounds a lot like gpu memory exhaustion. At some point when we hit a predetermined limit of visible textures we just start dropping them. The fact that using will-change: transform causes this makes that seem pretty likely. I'll try to get a frame viewer trace so I can see how many layers are being created here.
,
Oct 5
,
Oct 6
We've seen a huge increase in issues relating to this with Chrome 69. Here's a hopefully pretty consistent repro (Max OSX, Retina - there's some indication this doesn't repro on non-Retina displays): 1. navigate to https://paper.dropbox.com/doc/Lorem-ipsum--AOhPQEM_5AwJTTv2hId2hjgcAg-98LHZj7MSRTNAWpV4qHNZ 2. scroll around Many of the table cells will be empty, but they should all contain "lorem ipsum" content. This issue can also be reproduced with Google Docs.
,
Oct 8
I reproduced #c12 issue on Mac Retina, and Linux with --enable-prefer-compositing-to-lcd-text. Bisected to the following common range on Mac and Linux: https://chromium.googlesource.com/chromium/src/+log/a1dbad9..17ff2d43c17a32c06f0e0e7bb1a34a35abbe60ad. Suspecting https://chromium.googlesource.com/chromium/src/+/a3dfbb28e205cfc9d264b4ed4d0ccc7000a280bc.
,
Oct 8
Thank you, wangxianzhu@chromium.org for reproing the issue and pinpointing the source.
,
Oct 9
We are in the process of rolling out a stop-gap mitigation that will force re-rendering starting sometime tomorrow morning. The mitigation can be disabled like so: https://paper.dropbox.com/doc/Lorem-ipsum--AO3z5Hz_buR7oNPTghVcN1uVAg-98LHZj7MSRTNAWpV4qHNZ?disableTableRerender=1
,
Oct 10
I am pretty sure this is a duplicate of crbug.com/889492 . That issue was filed in time for it to be fixed for Chrome 70, but unfortunately not Chrome 69. The merge to Chrome 70 has not yet made its way out to a beta version (it's in 0.0.3538.49), but it has been released to Chrome 70 canary/dev. anbu@dropbox, could you please verify that it it is fixed? I verified the testcase in comment 13 was fixed.
,
Oct 10
Tested it on 71.0.3575.0 canary build with https://paper.dropbox.com/doc/Lorem-ipsum--AO3z5Hz_buR7oNPTghVcN1uVAg-98LHZj7MSRTNAWpV4qHNZ?disableTableRerender=1 and I can confirm that the rendering issue in tables is no longer there. Thanks for fixing the issue. cc @chrishtr@chromium.org
,
Oct 10
,
Oct 10
Thanks for everyone's help in diagnosing the issue. Unfortunately, I was still able to reproduce the first issue mentioned on reddit.com on both retina and non-retina displays on Chrome 71.0.3575.0. Is this issue still going to be addressed if it's been merged into that other issue?
,
Oct 10
The reddit issue seems different from the dropbox issue. We need another bisect.
,
Oct 10
I can't reproduce the issue on reddit. It seems no one from google has yet reproduced it. :( Hmm. Do you have an exact reliable sequence of actions to reproduce it? Also, the I'm not sure what is wrong about the output in the video from comment 7.
,
Oct 10
Sorry it's so hard to reproduce - I've attached a another video that hopefully makes it clearer what's going wrong. The easiest, and closest thing to a reliable way of reproducing is by scrolling very far down on a listing with lots of embeded content (/r/videos), clicking on a post to open the lightbox, then clicking play and scrolling down. When I do that, it's only happening about 2/3 of the time. Up above some people mentioned GPU memory exhaustion - is there any way to simulate that? Do you believe that there will be a fix on your side, or will we just need to cut down on our GPU memory usage?
,
Oct 11
I can repro fairly consistently in canary (71.0.3576.0) on Win 10. See attached screencast (and also crbug.com/892763 where I first reported this).
,
Oct 11
Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using chrome latest beta #70.0.3538.54 and latest canary #71.0.3576.0. Issue is not reproducible using the chrome reported version #69.0.3497.100 Bisect Information: ===================== Good build: 70.0.3525.0 Bad Build : 70.0.3526.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/d4ce97f15ace5e4431e8702fdce563fe67299b2f..6f271d300f12c96004ef68b6f6676ac123849463 From the above change log suspecting below change Change-Id: I20967bf4b00716e5c4ec2bac2e3781c81cdaa688 Reviewed-on: https://chromium-review.googlesource.com/1178043 obrufau@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding stable blocker for M-70 as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Oct 11
It's certainly not https://chromium-review.googlesource.com/1178043. Nothing else in that range looks particularly plausible either. Bisect may be unreliable due to inconsistency of repro. Routing back to Chris.
,
Oct 11
@skobes could you verify this and assign to sky@ if so?
,
Oct 11
I was unable to repro at either r543973 or r543976. I think r543974 is unlikely since that change affects only the browser compositor and not the renderer compositor. Furthermore it seems Aura specific and this bug is reported on Mac as well. I ran a new bisect and got https://chromium.googlesource.com/chromium/src/+log/1f3a2f04a3d7b5111ebafad83fbddce4e3f569f1..9d1ad1fd2c26e0707f9ae80b92595904e9fd0d6d but this is clearly bogus as r555676 only affects test code. It seems like older revisions are harder to repro, and newer revisions are easier. There may have been some recent change that increased the frequency. Here is a rendering trace from ToT Linux. The bug occurs around 19s. https://drive.google.com/file/d/1iF4R0MT9I-_dbUgEWyFTTiMrQ9zqVgDg/view?usp=sharing Can it be used to validate the theory of GPU memory exhaustion? I'm not sure where to look for that. It's interesting that it repros both with GPU raster (Windows) and without (Linux).
,
Oct 12
Third time's a charm? I've made sure to pressure my GPU by running two HD videos in MPCHC with MadVR renderer. Bisect info: 543288 (good) - 543294 (bad) https://chromium.googlesource.com/chromium/src/+log/72b68bc8..209644b1?pretty=fuller Landed in Chrome 67. There are three CLs that could be related: r543292 "Roll src/third_party/angle/ d92d9dd18..5eaddbd01 (11 commits)" r543291 "Reland "[SPv175] Enable SlimmingPaintV175 by default"" r543289 "[cc::SurfaceLayer] Allow cc::SurfaceLayer to stretch content via ui::Layer." I'd blame SlimmingPaintV175, but I can't disable it in 69+ since the switch was already removed.
,
Oct 12
The error message show by paint_chunks_to_cc_layer.cc (found by enne@ who filed bug 892855 ) seems really relevant.
,
Oct 12
,
Oct 12
Pending CL: https://chromium-review.googlesource.com/c/chromium/src/+/1278990. However, though I could reproduce the bug in this morning, I can't reproduce it now without the patch. I can see the error message in bug 892855 disappeared with the patch though. Can anyone help verify the patch if you can reproduce the bug?
,
Oct 12
,
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
Thanks woxxom@gmail.com for verification, and also for the bisect in #c30 which helped a lot. The CL missed the last canary build. Will wait for the next canary build and verify with it before requesting merge.
,
Oct 15
The NextAction date has arrived: 2018-10-15
,
Oct 15
,
Oct 15
Friendly ping to get an update as it is marked as RBS & stable release is coming very soon. Thanks..!
,
Oct 15
Confirmed that this seems fixed in Windows canary (72.0.3580.0).
,
Oct 15
,
Oct 15
This bug requires manual review: We are only 0 days from stable. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 15
The merge will be safe. The one-line change fixes the cause of the bug, and I see no risks.
,
Oct 15
,
Oct 15
,
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
Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
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 16
,
Oct 16
Thanks for everyone's help, the Redesign team at Reddit really appreciates it! If I understand the status/tags correctly, the fix has already been merged into Chrome 70 and 71?
,
Oct 16
Yes, the fix has merged into 70 and 71.
,
Oct 16
Great, thanks again!
,
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}
,
Nov 8
We are facing a similar issue. Please have look at https://bugs.chromium.org/p/chromium/issues/detail?id=903067 |
|||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Sep 19