Open
Bug 162122
Opened 22 years ago
Updated 2 years ago
stop paint suppression when vertical scrollbar appears
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
NEW
mozilla1.4alpha
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: perf, testcase)
Attachments
(1 file)
213 bytes,
text/html
|
Details |
Mozilla should draw what it has immediately when a vertical scrollbar appears. It currently seems to wait 1.2 seconds from when the page starts to load unless the page finishes loading during the first 1.2 seconds. Rationale: if the vertical scrollbar appears, the page layout should be stable. The appearance of the vertical scrollbar may have changed the layout, but loading the rest of the page is not likely to change it more. Additionally, starting to paint now won't slow down loading the rest of the page much, because the rest of the page is below the edge of the content area.
Reporter | ||
Comment 1•22 years ago
|
||
Updated•22 years ago
|
Updated•22 years ago
|
QA Contact: petersen → amar
Comment 2•22 years ago
|
||
Not going to be able to get to this for a while. nsbeta1-.
Updated•22 years ago
|
Comment 3•22 years ago
|
||
See bug 180241 : since dec 26th, we're experimenting with a default delay of 250 msec, instead of 1200. The final value might change though (500 ?)
Comment 4•22 years ago
|
||
This is appears to be rational solution. If one page of content has been loaded display the content. Otherwise, if painting has not occurred within the specified timeout display the content. Note: The scrollbar appearing is driven by frames being constructed which means the content notification interval may need to be smaller than what it is currently so frame construction will happen more frequently. Other mechanism's which affect the initial painting of the page including The PAINT_STARVATION_LIMIT in plevent.c and the paint suppression delay would need to be taken into account as well.
This sounds like a great idea to me. We should do this soon.
Comment 7•18 years ago
|
||
Is this still something to address soon?
I'm not sure if this is still a problem.
Reporter | ||
Comment 9•18 years ago
|
||
This is more of an idea for an optimization than a problem. Are you saying this optimization is no longer needed?
Now that the Firefox suppression timeout is only 250ms, I'm not sure if this is worth doing. Especially because it could hurt in non-unusual cases. For example, lots of pages have a sidebar that gets laid out first, which triggers a vertical scrollbar before the main content has come in.
Updated•15 years ago
|
Assignee: kmcclusk → nobody
QA Contact: amar → layout
Comment 11•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•