Spellcheck of a long line text over 24k characters consumes 60ms to paint.
Reported by
dukeyi...@gmail.com,
Jun 18 2018
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Steps to reproduce the problem: 1. Open a page with an editable text area that has spellcheck enabled and does not word wrap. At the time of this ticket creation, www.utilities-online.info/base64/ is an example of such a page. 2. Paste in the contents of the chrome_spellcheck_issue.txt file. The cursor should be at the end of the last line. 3. Click anywhere in the 2nd line (the one with the ~24,000 characters, which is the base64 representation of the "G" logo jpeg from the Alphabet home page). What is the expected behavior? The Chrome tab remains responsive. What went wrong? The Chrome tab stops responding. Task Manager shows the tab using 100% CPU. Performance recorder shows that Chrome is busy Painting. Did this work before? N/A Chrome version: 67.0.3396.87 Channel: stable OS Version: 10.0 Flash Version: It was observed that Chrome spellchecks the current line in a text area once the text cursor is set there with the mouse or keyboard. Disabling spellcheck avoids the described performance problem.
,
Jun 22 2018
dukeyin13@ Thanks for the issue. Tested this issue on Windows 10 on the reported version 67.0.3396.87 and the latest Canary 69.0.3469.3 by following the below steps. 1. Launched Chrome and navigated to www.utilities-online.info/base64/. 2. Downloaded the given text file and copy - pasted the content in the above site. 3. Checked the task manager and couldn't observe any high CPU usage on task Manager. Attached is the screen cast of the steps followed. Request you to please check and confirm if anything is missed from our end in triaging the issue. Also request you to retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations. Thanks..
,
Jun 22 2018
@susan.boorgula, in your own video, you can see your tab is using 98% - 105% CPU at 0:24 - 0:27.
,
Jun 22 2018
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
,
Jun 22 2018
,
Jun 22 2018
Most renderer time is spent on InlineTextBoxPainter::PaintDocumentMarkers. See attached screenshot and trace. It seems that we are spending O(n * m) time to paint markers on the super-long text node, where n = number of text boxes (namely, lines) and m = number of markers. However, this is a rather edge case that we need a super-long text node without any sentence separator (e.g., full stops, line breaks, ...). This eliminates almost all natural cases. This should be optimizable, as long as we don't increase code complexity by too much for this edge case.
,
Jun 25 2018
,
Jun 25 2018
,
Sep 19
Hi, I encountered this by pasting a relatively small amount of JSON into an input field and getting 30s+ pauses from paint calls. Not sure it's that much of an edge case, since it's easy to trigger with anything but English text.
Reproduction URL:
data:text/html,<input/><script>document.querySelector('input').value = '0a '.repeat(10000)</script>
This causes 10 second delays for me when doing anything with the text box.
Tested with Chromium 69.0.3497.100 in Linux
,
Sep 19
Maybe just try switching to iterating over text boxes then markers? Or whatever the opposite of the current code.
,
Sep 20
Idea: add an offset range to DocumentMarkerController::ComputeMarkersToPaint so that the function doesn't return all markers on the entire text node, but only those on the InlineTextBox or NG text fragment. This should reduce the total time spent on PaintDocumentMarkers to linear. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by krajshree@chromium.org
, Jun 19 2018