Closed Bug 72138 Opened 23 years ago Closed 23 years ago

Incremental page loading is broken

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: kmcclusk, Assigned: kmcclusk)

References

Details

Attachments

(1 file)

Patch to change the default for content.notify.interval from 1 sec to 1/4 sec
695 bytes, patch
Details | Diff | Splinter Review 
There have been reports that pages no longer load incrementally. After a long
pause the entire page is displayed.
Severity: normal → major
Target Milestone: --- → mozilla0.9
Incremental page loading seems to be working.

I tried created a very large document consisting of a <BODY> followed by
thousands of <P> tags. 
After a few seconds it displayed the top portion of the document while
continuing to load the rest of the document which took another (approx. 20seconds.)

I also tried creating a very large document consisting of a table with thousands
of rows. It also loaded incrementally.

I tried running using a 28k connection and loaded www.icq.com. Mozilla loaded
the top table incrementally.









The last few days, I've been seeing the following case, which may or may not be
related:  the page starts to load, and I see most of the content.  If hyperlinks
are included in the displayed content, they will light up on mouse hover (if
style is set for that).  Then suddenly, the entire page blanks out, and then I
see the exact same content load again.  During this second load, the same
hyperlinks and such can't be clicked until the page is nearly finished.  I
*think* it's only visible with a slower connection, and it doesn't seem to
happen on all sites.  Could this be the problem that was reported?  One site for
this was gamespot.com.
Blocks: 71668
we are not displaying pages as quickly as we could.  In many cases the
nsParser::OnDataAvailable is called multiple times (10+) without flushing any
tags. This leads to sluggish display of pages, especially on slow connections.
Even large local pages  take up to 5 seconds before anything appears with a fast
machine (750Mhz). If I change the content.notify.interval default in
nsHTMLContentSink from 1 second to 1/4 second pages display their initial
contents much faster.  In the local page case it went from 5 seconds to less
than 1 second..  The initial display of sites such as yahoo.com and icq.com with
a slow connection is much faster after changing the default as well.

The original content.notify.interval code was implemented by vidur@netscape.com
The default for content.notify.interval  has not changed since his original
checkin for bug 17325  . The comments in the bug lead me to believe that we have
not attempted to tune the default value given to content.notify.interval.
Status: NEW → ASSIGNED
You can test out the content.notify.interval change without having to apply the
patch. Just add the following pref:

user_pref("content.notify.interval",  250000);
jrgm's peformance tests show no degredation in performance when the pref is
changed from 1 second to 1/4 second. The tests do not show a performance hit
until the pref is set to 1/10 of second or below. 

When I check in the patch I'll add a comment explaining how the default value of
determined.

The only performance hit I have seen is loading large text documents. The
reflows generated as the result of the content appended are very inefficient so
increasing the number of reflows doubled the page load time in this case. I
filed a new bug to look at this issue bug 72885.
r=karnaze

sr=attinasi
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: