Highlights in the scrollbar are incorrectly shown and constantly updated when searching within a large document
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: whimboo, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: power)
With bug 1725555 fixed and being able to quickly iterate through found search items in a large document, I can see that the highlights as shown in the scrollbar are getting invalidated and updated in a constant manner even with the search term not changing at all.
Steps to reproduce:
- Open https://community.taskcluster-artifacts.net/It905wBLQGOFhFaIUiURXA/0/public/logs/live_backing.log
- Search for
ok
and enableHighlight all
- Quickly step through the found results by clicking the up and down arrows
After step 2 you will notice that the highlight is only visible for the first around 5% of search results. Means the scrollbar shows only a small purple section at the top but stays normal for all the rest. When scrolling down to the middle of the document there are still items highlighted in the document but not in the scrollbar.
Also with step 3 you can see that the highlights in the scrollbar are getting invalidated and redrawn on a constant manner.
Even with a single click onto one of the arrows the CPU load of the content process directly climbs up to 100% and stays there for a long time.
Here a recorded Gecko profile: https://share.firefox.dev/3l5v7JX
Reporter | ||
Comment 1•3 years ago
|
||
Maybe better to move to WebRender first given that this has the biggest impact in the recorded Gecko profile.
Comment 2•3 years ago
|
||
Searching for ok
and asking for Highlight All in that document is a pretty extreme case -- there are 85K+ occurrences. I don't know how the scrollbar highlights are implemented but my suspicion is that we basically create an element for each mark to be drawn, and trying to handle 85K of them is pretty overwhelming.
Searching for something like "test_end" (800+ occurrences) may be a more typical scenario; then repeatedly clicking the Next/Previous arrows doesn't bring the browser to its knees to the same extent, but it does still show quite sluggish performance updating the scrollbar highlights -- especially visible if you use the Find Again keyboard shortcut to rapidly skip through the results. The scrollbar highlights are repeatedly repainted (unnecessarily) with a lot of visible lag.
Comment 3•3 years ago
|
||
we add a display item for every search result it looks like. Maybe we should limit the number of scrollmarks we display or store or something.
Updated•2 years ago
|
Updated•16 days ago
|
Description
•