Incremental rendering is busted on fast connections

RESOLVED FIXED in mozilla1.2alpha

Status

()

Core
Layout
P1
major
RESOLVED FIXED
17 years ago
11 years ago

People

(Reporter: Jesse Ruderman, Assigned: Kevin McCluskey (gone))

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla1.2alpha
x86
Windows 98
hang, perf, testcase, topembed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.

Examples:

1. http://slashdot.org/article.pl?sid=02/03/07/2132243&mode=thread&light=1
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.

2. http://bugzilla.mozilla.org/buglist.cgi?email2=jrud&emailreporter2=1
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
great.

3. view-source:http://www.w3.org/TR/REC-html32 (see bug 129612)
For view-source, note that view-source:http://mpt.phrasewise.com/ *does* render
incrementally, since mpt.phrasewise.com loads slowly.  This case may not be a
regression.
(Reporter)

Updated

17 years ago
Keywords: hang, perf, regression
(Reporter)

Comment 1

17 years ago
Forgot to mention: that's 2002 030604 on Windows 98.
(Assignee)

Comment 2

17 years ago
reporter: Any idea on when the regression started? Do you know of an earlier
build that was working ok?
(Assignee)

Comment 3

17 years ago
Taking
Assignee: attinasi → kmcclusk

Comment 4

17 years ago
Changing Priority to P2.
Priority: -- → P2
(Reporter)

Comment 5

17 years ago
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
(Reporter)

Updated

17 years ago
Blocks: 114584

Updated

17 years ago
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
(Assignee)

Comment 7

17 years ago
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

Updated

16 years ago
Keywords: testcase

Updated

16 years ago
Blocks: 146917

Updated

16 years ago
Blocks: 149241
(Assignee)

Updated

16 years ago
Depends on: 157144

Comment 8

16 years ago
Reporter,

Are you still able to reproduce this in the current build ?
(Assignee)

Comment 9

16 years ago
nsbeta1+.
Keywords: nsbeta1+
Target Milestone: Future → mozilla1.2alpha
(Assignee)

Comment 10

16 years ago
This was fixed by checkin for bug 157144
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 11

16 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

Updated

16 years ago
Blocks: 176349
You need to log in before you can comment on or make changes to this bug.