Open Bug 1517850 Opened 5 years ago Updated 2 years ago

ensure layout is initialized soon enough during page load

Categories

(Core :: Layout, enhancement, P3)

Product:
Core
Component:
Layout
Type:
enhancement

Tracking

()

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Summary: ensure layout is initialize soon enough during page load → ensure layout is initialized soon enough during page load
Can you clarify what the problem is & what change is needed here? A few specific notes below; if you could clarify any/all points, it'd help me better understand what you're getting at & how to triage this bug etc.  (My confusion might be simply due to forgetting some details around document/viewer setup process; apologies if the answers seem obvious.)

(In reply to Olli Pettay [:smaug] from comment #0)
> currently we seem to delay Presshell/layout creation too much

Delay them where? Too much for what?

> at least because of
> https://searchfox.org/mozilla-central/rev/fef7f858efb695a76010b4c624da5277c16e95b3/modules/libpref/init/StaticPrefList.h#543-558

I'm not immediately seeing the connection between those prefs & layout. They seem to be about network<-->parser interactions, right? (and they come from https://hg.mozilla.org/mozilla-central/rev/9732d2b16662 )
Flags: needinfo?(bugs)
This is part of parser stuff and layout.
Basically, at some point parser thread creates an op to tell the main thread to start layout for the page
(and timers are for flushing ops from parser thread to main thread), then main thread 
at some point creates PresShell and initializes it (and painting still happens after a timeout, bug 1454529). And since RefreshDriver is needed to trigger all the vsync to happen, that is when vsync is even requested... and then we wait compositor to send the vsync and finally we'll paint.
Flags: needinfo?(bugs)
And the point here is that we do initial paint often too late (something bas and djvj discovered).
Bug 1514011 is also related to this, and probably others.

Needinfo'ing Henri so he's aware of this bug and can give any thoughts he may have.

Flags: needinfo?(hsivonen)

I did assign this to myself and I've discussed about this with Henri (on IRC) :)

Flags: needinfo?(hsivonen)

(In reply to Olli Pettay [:smaug] from comment #5)

I did assign this to myself and I've discussed about this with Henri (on IRC) :)

To recap for others:

  • The point at which the parser emits the "start layout" operation relative to the structure of the HTML document comes from the old parser. While I didn't write the relevant code in the old parser, the reason is easy to infer: Typically <head> is hidden, so letting layout uselessly react to insertions into <head> is avoided by starting layout once <body> is seen.
  • The parser thread queues up operations and moves them to the main thread notably:
    • On </script> end tag being parsed.
    • On </script> end tag after the script has finished executing on the main thread (speculatively parsed operations may have queued up on the parser thread).
    • On end-of-stream.
    • On timer.

From the above, we should expect the timer delay to affect the start of layout mainly on pages that don't have a bunch of scripts in head. If the timer delays seem to be affecting the layout start time pages that do have scripts in head, I don't have an immediate explanation.

Yeah, it is not just parser, but also things like bug 1454529 (paint suppression) and what not.
And given the current RefreshDriver setup, we need to get layout up and running very early so that
we don't need to wait for vsync too long when we actually do have some reasonable elements to paint.

(In reply to Henri Sivonen (:hsivonen) from comment #6)

To recap for others:

Thanks, it's very valuable to have this sort of background and useful info captured in bugs rather than disappearing into IRC logs where it's unlikely to be discovered by anyone doing bug archeology.

(In reply to Olli Pettay [:smaug] from comment #7)

And given the current RefreshDriver setup, we need to get layout up and running very early so that
we don't need to wait for vsync too long when we actually do have some reasonable elements to paint.

I'm unclear on how to square what Henri said in comment 6 about us starting layout once <body> is seen, and your concern that layout is starting too late. Anyway, I hadn't noticed you'd assigned this to yourself. I guess at the point you're looking for layout folks input you'll needinfo us and we can hash out what it is that you're concerned about. :)

Oh, and can you set a priority for this bug to take it off the triage queue?

Flags: needinfo?(bugs)
Priority: -- → P3
Depends on: 1521334

Need to get rid of paint suppression timer, bug 1454529.

Depends on: 1454529
Flags: needinfo?(bugs)
Depends on: 1521786
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.