Hidden element with huge amount of child elements causes long Update Layer Tree's
Reported by
hasat...@gmail.com,
Nov 23 2016
|
|||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.59 Safari/537.36 Steps to reproduce the problem: This is the shortest amount of steps I've been able to reproduce with: 1. Click the button that says "Step 1 and 3. Click here". 2. Click on the element that says "Step 2. Click here". 3. Click on the same element as in step 1: "Step 1 and 3. Click here". 4. Drag the element with the blue border around a bit. Notice jank. 5. Click outside the element with the blue border. 6. Drag the element with the blue border again. Notice no jank. The Timeline of step 4 to 6 looks like this: https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://dl.dropboxusercontent.com/u/3092780/TimelineRawData-20161123T135557.json Note that before the element with the blue border, there is a hidden element with 20000 elements. What is the expected behavior? No jank. What went wrong? Dragging is janky. Update Layer Tree's are ~20 ms on my machine in step 4, ~45 μs in steo 6. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.59 Channel: beta OS Version: OS X 10.12.1 Flash Version: Changing the button element to e.g. a div "fixes" the problem. If there are other workarounds, I'm interested.
,
Nov 24 2016
Unable to reproduce the issue on mac 10.12 with chrome version 55.0.2883.59 After loading the bug.html file, followed the procedure mentioned in comment #0 Observed the same behavior for step 4 and step 6 Please look into the attached screen-cast and let us know if any steps are missed while reproducing the issue.
,
Nov 24 2016
It certainly looks like the same steps, so I'm not sure why it's not reproducible. I'm attaching my recording.
,
Nov 24 2016
It drags with a lot of jank for me in step 4. In step 6, it drags fast again. Note - I renamed pointer to mouse, since I use Chrome 54 which does not support pointer events.
,
Nov 25 2016
hasather@ Could you please confirm is this issue is working fine on other browser? As per your original comment you have mentioned saying "Does this work in other browsers? as Yes" curious to know on which browser you were able to. Tested on firefox and safari as per your steps mentioned in the original comment, unable to perform step 4 & 6. Dragging goes unresponsive other than chrome.
,
Nov 28 2016
I have tested this issue on Windows 10 with chrome beta version 55.0.2883.59. Observed that for the step 4, time taken is approx 48.3 ms and step 6, the time taken is avg 20 ms. hasather@, Could you please look into the attached json file for Timeline and let us know the expected result so that we can triage this issue. Thank You...
,
Nov 28 2016
@kkaluri, that looks like the issue I'm seeing, yes. (However, it's much more serious than 48 ms vs. 20 ms when looking at the Update Layer Tree's in particular.)
,
Nov 28 2016
I can certainly repro this on ubuntu as well the fluidity of the drag is obviously smoother in step 6 vs step 4. There must be some algorithm that runs during UpdateLayoutTree that is more costly for hidden elements.
,
Nov 28 2016
The slowness is in the compositing update step (PaintArtifactCompositor::updateIfNeedeRecursive). Not sure yet why.
,
Nov 28 2016
It's before CompositingInputsUpdater runs at all, so it isn't overlap testing or anything like that.
,
Nov 28 2016
,
Nov 28 2016
The performance bug is in the call to LayoutView::commitPendingSelection from PaintLayerCompositor::updateIfNeededRecursiveInternal. It's taking a long time to commit the pending selection on every frame during the drag. This looks bad, raising priority. Yosin can you look?
,
Nov 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d160636f32a24e8fbe4a9d5569156972bfc3fdae commit d160636f32a24e8fbe4a9d5569156972bfc3fdae Author: chrishtr <chrishtr@chromium.org> Date: Mon Nov 28 17:17:47 2016 Add tracing for LayoutView::commitPendingSelection Committing selection can sometimes be slow; see the attached bug for an example. BUG= 668122 Review-Url: https://codereview.chromium.org/2536733003 Cr-Commit-Position: refs/heads/master@{#434671} [modify] https://crrev.com/d160636f32a24e8fbe4a9d5569156972bfc3fdae/third_party/WebKit/Source/core/layout/LayoutView.cpp
,
Nov 29 2016
Removing bisect label for now, Please add it back if it's required.
,
Nov 29 2016
Huge thanks for the hint with setting the component to Blink>Editing. `user-select: none` on #container (the element with the text "Step 2. Click here") is a workaround, and worked for me on the production site I'm working on. \:D/
,
Nov 30 2016
yoichio@, could you take look?
,
Nov 30 2016
I got a trace. There are 24 ms blockers. Most of time is consumed by 3 times of VisibleUnits::mostBackwardCaretPosition. It takes 4, 9 and 9 msecs.
,
Feb 11 2017
,
Mar 6 2017
,
Mar 7 2017
Created minimal sample:
<!DOCTYPE html>
<div id="div" hidden></div>
<p id="container" contenteditable>foo</p>
<p contenteditable>when selection null and has much hidden element,
WebViewImpl::handleInputEvent at mouse moving takes much time. <br>
Clicking on this contenteditable area, issue goes away.</p>
<div id="target" style="position:absolute;">Foo bar</div>
<script>
div.innerHTML = '<div>test</div>'.repeat(100000);
container.focus();
container.hidden = true;
window.addEventListener("pointermove", function(event) {
target.style.top = `${event.pageY}px`;
target.style.left = `${event.pageX}px`;
});
</script>
You can try this on:
https://jsfiddle.net/wu5whqnv/
,
Mar 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f26bb4852194e25309b9d0eab4ce7af1874ed53e commit f26bb4852194e25309b9d0eab4ce7af1874ed53e Author: yoichio <yoichio@chromium.org> Date: Tue Mar 07 09:31:25 2017 Add performance mousemove Description: Measures performance of WebViewImpl::handleInputEvent when selection null and has 20000 hidden elements Time on ToT(3033) Windows10 Z840: avg 18.513000000000023 ms median 17.909999999999968 ms stdev 1.3293024486549443 ms TEST=content_shell --run-layout-test WebKit\PerformanceTests\Editing\mouse-move-with-hidden-elements.html BUG= 668122 Review-Url: https://codereview.chromium.org/2734823006 Cr-Commit-Position: refs/heads/master@{#455048} [add] https://crrev.com/f26bb4852194e25309b9d0eab4ce7af1874ed53e/third_party/WebKit/PerformanceTests/Editing/mouse-move-with-hidden-elements.html [modify] https://crrev.com/f26bb4852194e25309b9d0eab4ce7af1874ed53e/third_party/WebKit/PerformanceTests/Skipped
,
Mar 10 2017
By the sample in #21, Wall duration of MessageLoop::RunTask is around 80ms.
,
Mar 16 2017
Unfortunately, WebKit/PerformanceTests/Editing/mouse-move-with-hidden-elements.html doesn't measure this performance appropriately because it goes through another code path to this issue's.
,
Mar 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d51024e6850f785d2bb364af8d63f742126f7a91 commit d51024e6850f785d2bb364af8d63f742126f7a91 Author: yoichio <yoichio@chromium.org> Date: Thu Mar 16 08:54:11 2017 Reduce canonicalization when dragging This CL avoids VisibleSelectionInFlatTree creation if VSInDOMTree is none in SelectionEditor.cpp. This reduces redundant canonicalization because VSInFlatTree availability == VSInDOMTree availability BUG= 668122 TEST= 1. Open the page on comment#21 described at the bug. 2. Open also chrome://tracing/ and record Input Latency. 3. Confirm Messaseloop::RunTask blocking time gets faster 3.7 times(from 64ms to 17ms). Review-Url: https://codereview.chromium.org/2741173002 Cr-Commit-Position: refs/heads/master@{#457376} [modify] https://crrev.com/d51024e6850f785d2bb364af8d63f742126f7a91/third_party/WebKit/Source/core/editing/SelectionController.cpp [modify] https://crrev.com/d51024e6850f785d2bb364af8d63f742126f7a91/third_party/WebKit/Source/core/editing/SelectionEditor.cpp
,
Mar 16 2017
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by ligim...@chromium.org
, Nov 23 2016Labels: M-55