If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Optimize the initial paint delay

RESOLVED DUPLICATE of bug 82777

Status

()

Core
Layout
RESOLVED DUPLICATE of bug 82777
13 years ago
13 years ago

People

(Reporter: Prognathous, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
Optimizing nglayout.initialpaint.delay is a frequent subject of discussion among
many Mozilla enthusiasts. Some of them claim that changing its value to 0 makes
"a huge difference". I couldn't verify this personally, but I don't rule out the
possibility that this pref does make a significant difference for others, as
it's greatly dependant on connection speed and other factors.

In addition, David Hyatt has recently described a new algorithm that he
implemented in Safari to further optimize the initial paint delay. More details
here: http://weblogs.mozillazine.org/hyatt/archives/2004_05.html#005496

Prog.

Comment 1

13 years ago
> that changing its value to 0 makes "a huge difference"

This is intriguing as it would mean that the whole gymnastics/coding of the
paint suppression is not useful for those users.
Paragraph 1 and paragraph 2 of comment 0 are two totally different bugs.  Since
the summary of this bug indicates it's about the first paragraph,

*** This bug has been marked as a duplicate of 82777 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
I guess you're using (inappropriately) the term "paint delay" in the second
paragraph.  What Dave Hyatt described is *not* paint delay and shouldn't be
called that.

If you want to file a bug entitled "Optimize when and how to start displaying
content for a loading page" with the second paragraph of comment 0, feel free. 
Reusing the current bug will lead to lots of users whining about the paintdelay
pref in what could otherwise be a useful bug.

Comment 4

13 years ago
Re: "Optimize when and how to start displaying content for a loading page"

That would be bug 51202. The bug that prompted me to file bug 82777 was bug
72138. Following a few links from there led me to that bug (bug 51202), which
seems to be much closer to what the reporter intends.

Currently, there is only one pref (content.notify.interval -- see bug 72138) to
decide when the available content is flushed for display (a.k.a. incremental
reflow). Maybe having another pref (say content.notify.initial) could allow the
initial display to be treated differently, while waiting for the idealistic, but
more complex, bug 51202.
You need to log in before you can comment on or make changes to this bug.