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

tested with build 2000090808..

WFM on win2000

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.

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

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...

Dividing up Claytons bugs to triage

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.

Rods: I'm sending this back to you. I don't have the cycles to track it down. Please try to find another owner.

next release

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.

I load that url in viewer with profiling on (eazel-profile), you can see results at: http://www.student.oulu.fi/~tomilepp/mozilla/2000-10-29.html 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.

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.

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.

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

Bug 60371 may be related.

ftp://ftp.funet.fi/pub/doc/dictionaries/Finnish/words.finnish Very slow on my mashine (AMD Athlon 1333 MHz, 512 PC133 CAS2 RAM). Using Mozilla 2002020208 on Windows XP.

http://non-us.debian.org/debian-non-US/pool/non-US/main/m/mozilla/mozilla_0.9.9-1.diff.gz is another, very slow, example. changing summary for easier searching

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.

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 ?

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.

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

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.

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.

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.

This is not a plain text file, but it is very simple HTML. http://www.tuxedo.org/~esr/jargon/jargon.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

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" stuff.

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... ;)

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 ***

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.

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 later. 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.

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...

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.

OK, sounds reasonable. Anything I can do to facilitate said pounding?

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.

Comment on attachment 143892 [details] [diff] [review] Same as diff -w a=brendan@mozilla.org for 1.7 final. /be

Checked in for 1.7. Thanks to roc for doing the hard part!