Closed Bug 129640 Opened 18 years ago Closed 18 years ago

Incremental rendering is busted on fast connections


(Core :: Layout, defect, P1, major)

Windows 98





(Reporter: jruderman, Assigned: kmcclusk)


(Blocks 1 open bug)


(4 keywords)

When loading some long pages, Mozilla displays nothing until the entire page is
done rendering.  During this time, the throbber stops, and I cannot interact
with other Mozilla windows.  Depending on the length of the page, Mozilla may
effectively be frozen, and I have no way to close the problematic window.

Incremental rendering is necessary for making the browser fast in a useful way,
whether the limiting factor is bandwidth or CPU time.  Mozilla currently does a
good job of incremental rendering for slow pages, but it does *worse* when the
same page is loaded over a fast connection.  I believe this is a regression.


Incremental rendering at Slashdot used to work very well in Mozilla.  It used to
be that Mozilla was the only browser that would display slashdot comments as the
page loaded (although this only worked in light mode).  IE only displays the
article as the comments load (again, only in light mode).  Because of this
regression, IE's incremental rendering now beats ours.

Loading a 800-bug list (ALL reporter:jrud) sometimes hangs Mozilla for a few
seconds, and a 2000-bug list (UNCO) sometimes hangs Mozilla for more than a few
seconds.  I think the sometimes depends on Bugzilla's load.  When Mozilla
doesn't hang, it displays the bug list one or several bugs at a time, which is

3. view-source: (see bug 129612)
For view-source, note that view-source: *does* render
incrementally, since loads slowly.  This case may not be a
Keywords: hang, perf, regression
Forgot to mention: that's 2002 030604 on Windows 98.
reporter: Any idea on when the regression started? Do you know of an earlier
build that was working ok?
Assignee: attinasi → kmcclusk
Changing Priority to P2.
Priority: -- → P2
Tested with a slashdot story, clearing the cache after launching each build:

broken: (2000 december)  mozilla 0.6
broken: (2001 050515)    mozilla 0.9
broken: (2001 080110)    mozilla 0.9.3 
broken:  2001 101803
broken:  2001 120703
broken:  2002 012708
broken:  2002 020703
broken:  2002 030803     mozilla 0.9.9+ trunk

Ok, so this isn't a regression in Mozilla.  Slashdot or my Internet connection
must have become faster.  Still, this bug makes it less pleasant to read Slashdot.

By the way, the same several-second freeze happens if I load a copy of the same
Slashdot story from my hard disk.
Keywords: regression
Blocks: 114584
Keywords: mozilla1.0
Loading an 8mb HTML file from disk does this every time.  Loading view source on
a 3mb HTML file will have the same exact effect (disk is irrelevant at that
point, since view source comes from cache).
Blocks: 84707
Moving to P1.

I believe this bug is the result of event starvation caused by the reflow
PL_Events being processed at a higher priority than the paint and other events.
 Any fix for this would probably require changing the order in which we process
events or how we schedule reflow events. A fix for this would be risky in the
Mozilla1.0 timeframe.
Priority: P2 → P1
Target Milestone: --- → Future
Keywords: testcase
Blocks: 146917
Blocks: 149241
Depends on: 157144

Are you still able to reproduce this in the current build ?
Keywords: nsbeta1+
Target Milestone: Future → mozilla1.2alpha
This was fixed by checkin for bug 157144
Closed: 18 years ago
Resolution: --- → FIXED
batch: adding topembed per Gecko2 document
Keywords: topembed
Blocks: grouper
You need to log in before you can comment on or make changes to this bug.