Lots of Textareas in a table is really slow
Reported by
martin.l...@qualiconsult.fr,
Mar 3 2017
|
||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Steps to reproduce the problem:
1. open a new page with about:blank
2. Run this snippet in console :
document.getElementsByTagName("body")[0].innerHTML = "<table id='mytable'></table>";
for (let i=0; i<=3000; i++) {
let tr = document.createElement("TR");
let td = document.createElement("TD");
let txta = document.createElement("TEXTAREA");
td.appendChild(txta);
tr.appendChild(td);
document.getElementById("mytable").appendChild(tr);
};
3. Try to edit some textareas, it's really slow
4. It work good with the same amount of textareas without table (snippet example :
for (let i=0; i<=3000; i++) {
let txta = document.createElement("TEXTAREA");
document.getElementsByTagName("body")[0].appendChild(txta);
};
)
What is the expected behavior?
Edit textareas without slowness
What went wrong?
It's really slow
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 56.0.2924.87 Channel: stable
OS Version: 10.0
Flash Version:
First i thinked it was juste because of the amount of textareas, but i tried outside of table, and it works well.
,
Mar 3 2017
Simplified repro without tables, just the textareas: 1. open the attached html 2. open Chrome's Task Manager (Shift-Esc key or via menu) 3. click any textarea, press any letter key like "a" and hold it for 5 seconds EXPECTED: text characters appear with the same speed; CPU usage of the tab stays low, preferably 1% or less OBSERVED: text characters appear in chunks of 3-5 or more CPU usage of the tab maxes out CPU core e.g. 12.5% on 8-core i7 CPU here, arguably 25% on 4-core, 50% on 2-core and 100% on singe-core CPUs. Judging by chrome://tracing the time is spent in ScrollingCoordinator::updateAfterCompositingChangeIfNeeded called from UpdateLayerTree so it looks like Chrome needlessly checks everything on the page after each character typed by the user even though the textframe size hasn't changed. P.S. adding spellcheck="false" doesn't change the observed behavior.
,
Mar 3 2017
,
Mar 3 2017
It should be noted that modern Chrome versions are much faster (at least 45-58) than Chrome 31 which lags incredibly with the html in #2.
,
Mar 6 2017
Able to reproduce this issue on Mac 10.12.3, Win-10 and Ubuntu 14.04 using chrome reported version #56.0.2924.87 and latest canary #59.0.3030.0. This is a non-regression issue as it is observed from M50 old builds. From M-45 and lower builds till M-30, the code snippet is throwing an error in the console. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Mar 9 2017
,
Mar 16 2017
Looks like ScrollingCoordinator::updateAfterCompositingChange is taking ~100ms on the page in #2. Trace attached. flackr@, do you know who owns Blink-side compositing?
,
Mar 17 2017
The paint team owns blink-side compositing. +wkorman, who will be working in a related area for SPv2 soon.
,
Mar 27 2017
,
Sep 27 2017
No activity for 6 months, lowering priority.
,
Sep 28
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 28
Seems fast enough now on a Mac Retina. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by martin.l...@qualiconsult.fr
, Mar 3 2017