687861 - Horizontal scrolling in Orion with very long lines is slow

Status: RESOLVED FIXED

(DevTools :: General, defect, P2)

Description

[(no longer active)]

STR:

1. Go to <https://bugzilla.mozilla.org/js/yui/yahoo-dom-event/yahoo-dom-event.js?1303753510>, select all, copy.
2. Go to scratchpad, select all, paste.
3. Scroll horizontally.
4. Now go to data:text/html,<textarea rows=10 cols=80 wrap=off>, paste.
5. Scroll horizontally.

The scrolling in textarea is very smooth, the scrolling in scratchpad is slow and choppy.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I profiled this on Mac.  Specifically, I held my mouse down on the right scroll arrow and then started the profiler, waited a bit, and stopped it, using keyboard shortcuts (Option+esc).

The short of it is that 84% of the time is under reflow triggered from getBoundingClientRect calls coming off a scroll event.

I have no idea what the heck Orion is doing from horizontal scroll events, but it may want to stop doing it.  Looking at the profile, it includes at least lots of calls to getBoundingClentRect interspersed with .length gets on textnodes, .firstChild and .nextSibling gets on nodes, CSS property setting, CSS property getting, .scrollLeft gets, .style gets, createDocumentFragment calls (!), .clientHeight gets, .rows gets on tables, .selection gets on windows, .clientWidth gets, .scrollTop gets, .scrollWidth gets, .cells gets on table rows, .documentElement gets, .previousSibling gets, .style.height sets, etc, etc, etc.

The combination of style changes and reflow flushes is presumably what really kills performance here.  Why is Orion doing that, exactly?

Comment 2

[Kevin Dangoor]

This is the upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354435

Comment 3

[Boris Zbarsky [:bzbarsky]]

That upstream bug is about a hang loading a file with a really really long line in the editor.

We need separate upstream bugs to track this and bug 687865, I think.

Comment 4

[Kevin Dangoor]

(In reply to Boris Zbarsky (:bz) from comment #3)
> That upstream bug is about a hang loading a file with a really really long
> line in the editor.

I put them together thinking that there may be one solution on their end and they can break it up based on the implementation.

But, I think your suggestion to break up the bug is better for ensuring that separate issues don't get lost.

New additional upstream bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=358628

Comment 5

[Dave Camp (:dcamp)]

We're doing developer tool prioritization, filter on 'brontozaur'
to ignore the spam.

Comment 6

[Mihai Sucan [:msucan]]

This bug is now fixed upstream and the code has been integrated, see bug 702331.

If there are other or similar performance issues, please file separate bug reports. Thank you!