[FIXr]poor performance scrolling large plain text files (scrolling is slow)

RESOLVED FIXED in mozilla1.8alpha1



Layout: View Rendering
18 years ago
4 years ago


(Reporter: janne hayrynen, Assigned: bz)


(Blocks: 1 bug, {fixed1.7, perf})

fixed1.7, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(3 attachments)



18 years ago
scrolling the plain text file in the above url is painfully slow, on a 600mhz
machine i get about 2 updates per second.

Comment 1

18 years ago
tested with build 2000090808..

Comment 2

18 years ago
WFM on win2000

Comment 3

18 years ago
I can hardly get this page to render on my linux system, much less scroll.
This doesn't seem to be any of the existing scroll/perf bugs so confirming and
adding perf keyword.
Ever confirmed: true
Keywords: perf

Comment 4

18 years ago
How about loading this page from harddisk? Is it still slow? If no, could be
netwerking issue. If yes, I have no idea where this goes (editor?)

on win98, there is a small noticable degrade in speed

Comment 5

18 years ago
loading this file from harddisk it takes 2.5 minutes to render with 100% load on
a k7/600 and scrolling is just as slow as before.
-> Layout.  A profile would help...
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
Dividing up Claytons bugs to triage
Assignee: clayton → rods

Comment 8

18 years ago
This document is certainly an edge case. Nav 4.x loads faster and scrolls 
faster. Rick assigning this to you because you may have a better feel where we 
should start. Or maybe this is a dup of an obviously known bug.
Assignee: rods → rickg

Comment 9

18 years ago
Rods: I'm sending this back to you. I don't have the cycles to track it down. 
Please try to find another owner.
Assignee: rickg → rods

Comment 10

18 years ago
next release
Target Milestone: --- → Future

Comment 11

18 years ago
hmm. a few things i noticed:
even just moving mouse over the window with this file loaded causes 100% cpu
load, and selecting is also dead slow.

Comment 12

18 years ago
I load that url in viewer with profiling on (eazel-profile), you
can see results at:


Profiling adds some overhead, so dont look so much on seconds, call counts
should be real numbers thought. I only profiled initial layout, not scrolling.

Comment 13

18 years ago
3/12 04 WinNT

Scrolling is plenty fast on NT.  Loading this page though, brought my entire app
to a standstill.  None of my windows would respond while this was loading initially.

Comment 14

18 years ago
with linux build 2001031205 scrolling the URLs plain text file is still
agonizingly slow, less than 2 updates/second on a 600mhz machine, which might be
even slower than it used to be when i first reported this.

loading the page is veeery slow too, as you described.

there are also few other issues with large plain text files that should probably
be reported separately:

-one such thing is the enormous amount of GetFrameForPoint() calls launched on
mouse movement that causes cpu usage to jump to 100% on even smallest mouse
moves. it's really _enormous_ if you compare it with GetFrameForPoint() calls
launched when mousing over normal html files.

-cpu usage on expose/repaint.

Comment 15

17 years ago
Same thing under MacOS. Very Slow. For fun just download a log file from a Web
Server...  the scrolling is "agonizingly slow". 

Comment 16

17 years ago
Bug 60371 may be related.


17 years ago
Blocks: 100951

Comment 17

17 years ago

Very slow on my mashine (AMD Athlon 1333 MHz, 512 PC133 CAS2 RAM). Using Mozilla
2002020208 on Windows XP.


17 years ago
Priority: P3 → --
is another, very slow, example.

changing summary for easier searching
Summary: poor performance scrolling large plain text files → poor performance scrolling large plain text files (scrolling is slow)

Comment 19

16 years ago
Status update: This page is still slow on 2002050504 win32 on win2kpro.

What's more interesting is that all Moz pages are slow while this page is
loading.  I have it in another tab and trying to update this bug and this page
is slow in scrolling as well.

Comment 20

16 years ago
WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531   and RC3

Please have a look on bug 100951 !

Can we close this bug ?  keywords --> qawanted ?

Comment 21

16 years ago
still slow with rc3 on linux. i now have 1.4ghz athlonxp and i get about 3
updates per second scrolling this file.

other things to note, while not necessarily related to scrolling, rendering this
file from disk takes 15 seconds and redrawing when the window comes on top takes
about 3 seconds.

Comment 22

16 years ago
I get the same thing on my Tosh Sat Pro 6100. Changing the Keyboard section of
the XF86Config file has no discernable effect.

Comment 23

16 years ago
Re Comment 17, works fine for me with WinXP and build 2002-09-27.

Can someone retest with a new build on a Linux machine.

Comment 24

16 years ago
Reply to comment 23.
I still have the same problem here. The scrolling gets slower and slower while
the file is downloading. And when it finishes the whole file (make sure you wait
to the end) it is extremely slow. I'm currently using build 2002092808.

Comment 25

16 years ago
Linux 2002092905

No improvements since last time i checked. This time about 25 seconds to load
and 3-4 updates per second when scrolling. Redrawing when window comes on top
takes ~2 seconds.

Comment 26

16 years ago
This is not a plain text file, but it is very simple HTML.


Both selection and scrolling are very slow (comparitively) for this page.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Created attachment 120384 [details]
Profile of scrolling this page
So the problem seems to be that the two main culprits
(nsBlockFrame::PaintChildren and nsBlockFrame::PaintFloaters) both have to walk
the entire line list to paint.  Which means, in this case, that every repaint on
a one-line scroll has to walk this huge line list and check, for every line,
whether that line intersects the dirty rect (for PaintChildren) and whether that
line contains floaters (for PaintFloaters).

We could maybe keep the "has any floaters at all" information in the block frame
itself... but I'm not sure what we can do about the "line intersects dirty rect"
Most blocks obey the invariant that the sequence of "line->combinedArea.y"s is
non-decreasing and the sequence of "line->combinedArea.YMost()"s is also
non-decreasing. So how about this: keep a bit in the block that is set only if
the invariant holds. We can clear the bit at the beginning of reflow and set it
during any "pass over all lines" that we do (e.g., during painting). Also keep
in the block a reference to a line, let's call it the cursor. When we paint, if
the invariant bit is set then we can search for the first line whose
line->combinedArea.YMost > damageRect.y and start painting from there. We can
also stop when line->combinedArea.y >= damageRect.YMost. The search for the
first line can start from the cursor and go either forward or back; we reset the
cursor to the new first line.
Ooh.  That sounds promising, yes... ;)
Assignee: rods → roc
Component: Layout → Layout: View Rendering
QA Contact: chrispetersen → ian
Target Milestone: Future → ---
This should be fixed by my patch in bug 51938, which addresses painting as well
as event handling.

*** This bug has been marked as a duplicate of 51938 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
roc, that patch still leaves the O(N) walk in PaintFloats().  With the patch
applied, scrolling the URL in the URL field of this bug spends 57% of time in
PaintFloats() (and only 3% in PaintChildren()).

I really wonder whether we can store a flag that says that none of the lines
have floats... it could be used to optimize more than just PaintFloats.
Resolution: DUPLICATE → ---
Is there any particular reason why PaintFloats needs to crawl the lines, instead
of just iterating through the block frame's child floater frame list? Is it
something to do with paint ordering?
Floats are _really_ not my forte... ;)  David, do you know the answer to comment 33?
OK, ordering can't possibly be an issue here.  nsBlockFrame::BuildFloatList()
(called after every reflow) ensures the invariant that mFloats is linked in
exactly the same order that traversing the lines gives.

Of course BuildFloatList has all these XXX comments about it being a perf
problem  and needing to go, but I presume that whatever we replace it with will
maintain the same invariant?
Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

With this patch, testing on that Finnish dictionary in the URL bar, I see
the following changes of behavior:

1)  Holding down the arrow key or pgup/pgdown key only uses about 40% of CPU,
    not 100% on my machine.
2)  Scrolling is smooth, not choppy.
3)  Releasing the arrow key makes scrolling stop immediately, not seconds
4)  A realtime profile shows almost all the time spent in __libc_poll.
5)  A non-realtime profile shows that the function most time is spent in
    (2.7% of total) is nsDOMEvent::QueryInterface (called from
    nsXBLWindowHandler::WalkHandlersInternal, mostly).

This may even be safe enough to land in beta, given what I said about the
BuildFloatList() invariant above...  If you think it's not, please say so.
Attachment #143892 - Flags: superreview?(dbaron)
Attachment #143892 - Flags: review?(dbaron)
Attachment #143892 - Flags: superreview?(dbaron)
Attachment #143892 - Flags: superreview+
Attachment #143892 - Flags: review?(dbaron)
Attachment #143892 - Flags: review+
Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

Could we take this for 1.7b?  This makes scrolling on very long pages much much
more pleasant...
Attachment #143892 - Flags: approval1.7b?

Comment 40

15 years ago
Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

trying shut down to get beta out tomorrow morning.  let's try and get a few
people to pound on this and maybe take for 1.7 final if its agreed that the
risk is small and nothing turns up.
Attachment #143892 - Flags: approval1.7b? → approval1.7b-
OK, sounds reasonable.  Anything I can do to facilitate said pounding?
Assignee: roc → bzbarsky
Summary: poor performance scrolling large plain text files (scrolling is slow) → [FIXr]poor performance scrolling large plain text files (scrolling is slow)
Target Milestone: --- → mozilla1.8alpha
Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

OK, I've been running with this for a bit, and I've not run into any problems. 
I think this is safe enough for 1.7.
Attachment #143892 - Flags: approval1.7?
Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

a=brendan@mozilla.org for 1.7 final.

Attachment #143892 - Flags: approval1.7? → approval1.7+


15 years ago
Keywords: fixed1.7
Checked in for 1.7.  Thanks to roc for doing the hard part!
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.