Web: report engine boot phase before callMain blocks the main thread - #6
Open
octopusburrow wants to merge 3 commits into
Open
Web: report engine boot phase before callMain blocks the main thread#6octopusburrow wants to merge 3 commits into
octopusburrow wants to merge 3 commits into
Conversation
After the download completes the loading bar sits at 100% while callMain runs the engine's synchronous start-up (module/physics init and, on WebGPU, shader/pipeline compilation). The page looks frozen and Chrome raises 'Page Unresponsive'. Add an opt-in onStatusChange config callback, fired with a boot-phase message and given a paint yield (double rAF) before the blocking call, and wire it into both bundled HTML shells.
…blocks The double-rAF yield was measured (CDP screencast, two runs) failing under post-download main-thread load: both rAF callbacks fired 2-8ms apart with no compositor frame between them, so the phase message never reached the screen once. Align to a frame boundary with a single rAF, then allow the compositor 100ms to present the committed change; keep an absolute 1s fallback for background tabs where rAF is suspended.
The splash is absolutely positioned, and positioned elements paint above normal-flow content regardless of DOM order — so the phase line rendered underneath the opaque splash (measured: elementFromPoint at the text's center hit #status-splash; compositor frames pixel-identical across the text mutation). Position it like the progress bar, just beneath it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After the download completes, the loading bar sits at 100% while
callMainruns theengine's synchronous start-up (module/physics init; on WebGPU, shader/pipeline
compilation) — several seconds of apparent freeze, sometimes long enough for Chrome's
"Page Unresponsive" while the page is still in fact loading correctly. This adds an
opt-in
onStatusChangeconfig callback fired with a machine-readable boot-phase token(
'shader-compile'when a pre-initialized WebGPU device will compile pipelines,'engine-init'otherwise; the shell owns the display text), plus a paint yield beforethe blocking call: one rAF to reach a frame boundary, then ~100ms for the compositor to
present, with an absolute run-once fallback for backgrounded tabs where rAF is
suspended. A double rAF is not sufficient — measured by compositor capture, under
post-download load both callbacks fire back-to-back with no frame between them. The
yield also gives the event loop a task boundary, resetting Chrome's responsiveness
watchdog, so one repaint informs the user and defers the "Page Unresponsive" prompt;
heavier chunked-yield schemes aren't warranted for a one-time boot cost. The phase line
is positioned like the progress bar, since the absolutely-positioned splash paints over
normal-flow content. Both bundled shells are wired up; the WebGPU shell also corrects
renderingDriverin its config when falling back to GL, so the reported phase matchesthe driver that actually runs.
No change when the callback isn't set. The freeze duration is unchanged — this makes it
legible, not shorter. Verified with compositor-side captures: the phase message is on
screen for the whole blocking span.