UpdateLayerTree is very slow on Google Drive and makes animations janky
Reported by
espr...@gmail.com,
Oct 13
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10895.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.95 Safari/537.36 Steps to reproduce the problem: 1. Load Google Drive: https://drive.google.com/drive/my-drive 2. Scroll up and down so the header shows and hides. What is the expected behavior? Should be fast. What went wrong? UpdateLayerTree takes up 40ms per frame on the main thread. The animation is very slow. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 69.0.3497.95 Channel: n/a OS Version: 10895.56.0 Flash Version:
,
Oct 13
Btw this is on a high end Chromebook Pixelbook device.
,
Oct 15
Can someone on the team with a Pixelbook take a look? Mine is ordered but not yet here.
,
Oct 22
,
Nov 15
Bump. Anyone with a Pixelbook to confirm this?
,
Nov 19
Double-bump. Maybe someone could recommend someone else that might have a pixelbook, and I'll cc them here?
,
Nov 20
This should be reproducible on probably any chromebook (certainly any high dpi one). Try a Samus or a Caroline?
,
Nov 20
chrishtr@, I marked this with Needs-Bisect yesterday - that's the correct tag to get someone to bisect it overnight, correct?
,
Nov 20
I can reproduce the slowness on Linux. Removing needs-bisect. For future reference: 1. Needs-Bisect is not supported on ChromeOS, due to lack of a script to do per-revision bisects. 2. You must add a milestone label for Needs-Bisect to be noticed by the testers.
,
Nov 20
The reason for the compositing update step in this case is because we currently have a slow path that invalidates sticky constraints and re-computes compositing inputs on scroll. The reason the compositing inputs are slow to compute is that there are a lot of PaintLayers on the page.
,
Nov 20
Second, even for composited layers we do a GraphicsLayerUpdate steps if it's not the root composited layer. Neither of these reasons should be required over time and we are continuously optimizing. I think the first can actually be removed now. It was added in https://chromium-review.googlesource.com/c/chromium/src/+/994462/ because sticky offset was at the time baked into paint offset. That has sinced been fixed as part of the BGPT milestone in https://chromium-review.googlesource.com/c/chromium/src/+/994462/. Will try to remove that now. The second slowness I will have to look into further.
,
Nov 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/25f5e3880294e41f2f0c23923b281dfb7f2dc237 commit 25f5e3880294e41f2f0c23923b281dfb7f2dc237 Author: Chris Harrelson <chrishtr@chromium.org> Date: Thu Nov 22 05:08:15 2018 Stop re-computing compositing inputs for scrollers with sticky descendants. This was added in revision 548120 because at the time paint offset baked in sticky position. This was since fixed in revision 590578 that factored sticky position into a transform paint property node rather than paint offset. All that is required is to re-compute paint properties for the scroller and all sticky descendants, in order to update the scroll offset and sticky transform offset. The latter is accomplished by a call to PLSA::InvalidatePaintForStickyDescendants() in PLSA::InvalidatePaintForScrollOffsetChange(). Bug: 895109 Change-Id: Ied7ef8fd15db4f5c3d546f0f06f1adf3cf1e26c8 Reviewed-on: https://chromium-review.googlesource.com/c/1345031 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#610305} [modify] https://crrev.com/25f5e3880294e41f2f0c23923b281dfb7f2dc237/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc
,
Jan 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/38c20f78b9826529f672e6db5baec01a60c2260f commit 38c20f78b9826529f672e6db5baec01a60c2260f Author: Mason Freed <masonfreed@chromium.org> Date: Wed Jan 16 01:30:35 2019 Remove extra calls to SetNeedsGraphicsLayerUpdate In non-BGPT mode, we only need to do a kGraphicsLayerUpdateLocal update, and in BGPT mode, we now call SetNeedsCommit() directly from PropertyTreeManager::EnsureCompositorTransformNode, so no graphics layer update is needed at all. Bug: 895109 Change-Id: I970b29bc05a43720cfb9747bfcfa50e42dc8639e Reviewed-on: https://chromium-review.googlesource.com/c/1403639 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Mason Freed <masonfreed@chromium.org> Cr-Commit-Position: refs/heads/master@{#622979} [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/cc/layers/layer.h [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/renderer/core/page/scrolling/scrolling_coordinator_test.cc [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/renderer/platform/graphics/compositing/paint_artifact_compositor.cc [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/web_tests/fast/events/touch/compositor-touch-hit-rects-scroll-expected.txt [modify] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/web_tests/paint/invalidation/compositing/scrolling-neg-z-index-descendants-expected.txt [add] https://crrev.com/38c20f78b9826529f672e6db5baec01a60c2260f/third_party/blink/web_tests/virtual/stable/paint/invalidation/compositing/scrolling-neg-z-index-descendants-expected.txt
,
Jan 18
(5 days ago)
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by espr...@gmail.com
, Oct 1366.8 KB
66.8 KB View Download
88.1 KB
88.1 KB View Download