Open Bug 854425 Opened 9 years ago Updated 3 years ago
Resizing the browser horizontally while on a word-wrapped plain text page is janky
Open the attached plaintext file and resize the browser window horizontally. The browser janks pretty bad as it tries to do the word wrap calculations. A quick profiling run shows that most of the time is spent in layout::DoReflow. I understand that doing word-wrap is inherently more expensive than no word-wrap, but there should be some kind of optimizations we can make here.
It seems like interruptible reflow ought to help here, unless there's a non-interruptible flush happening (worth checking) or something prevents interruptible reflow from kicking in.
I placed a breakpoint in PresShell::ProcessReflowCommands and resized the window. It looks like it's already using an interruptible reflow: http://screencast.com/t/8Ws5Ed80rM Could I be missing something here?
As long as aInterruptible is *always* true. Sometimes true isn't good enough; the jank could come from the one time it isn't. Or it could come from not having something that would lead to actually useful interrupting in a plaintext document... which seems entirely possible as well.
There are two uninterruptible reflows coming from: 1) http://hg.mozilla.org/mozilla-central/diff/c3956cae4197/browser/base/content/browser.js 2) http://hg.mozilla.org/mozilla-central/annotate/8d09f003e087/browser/base/content/tabbrowser.xml#l3440 both of which are triggered on "resize" events. Removing the calls to .clientWidth and .boxObject.width removes all instances of uninterruptible reflows, but there is still noticeable lag compared to the non-word-wrap view (especially when expanding horizontally).
I should note that both of those links in comment #4 probably only cause reflows for chrome, not content.
Tested in Firefox Nightly 63.0a1 (2018-08-16) (64-bit), the linked testcase, I don't see any jankiness.
You need to log in before you can comment on or make changes to this bug.