utilityLayerScene.executeWhenReady never fires (silent hang; blocks validation test idx 170)

[bkaradzic-microsoft]

Summary

Scene.executeWhenReady on a UtilityLayerRenderer's utilityLayerScene never fires on Babylon Native, silently. Any content that waits on it hangs forever with no error, no console output, and no stderr.

This is what keeps Playground validation test idx 170 "Nested BBG" (#ZG0C8B#12) excluded, and it is independent of any in-flight rendering work.

Repro

Snippet https://snippet.babylonjs.com/ZG0C8B/12. It loads scenes/Alien/Alien.gltf, attaches a BoundingBoxGizmo, then drives frames manually and waits for the gizmo's utility layer to become ready:

const id = setInterval(() => { engine.beginFrame(); scene.render(); engine.endFrame(); });
gizmo.gizmoLayer.utilityLayerScene.executeWhenReady(() => { clearInterval(id); resolve(scene); });

The clearInterval is the loop's only exit.

From the Playground validation app:

Playground.exe --headless --include-excluded --test-index=170 app:///Scripts/validation_native.js

Note: use --test-index=170, not --test="Nested BBG". Two tests share that title — idx 24 is enabled and passes in ~2s, and since --test= is a substring match, filtering by title silently measures the wrong one.

Observed

The callback never runs. The scene renders correctly and at full speed the entire time — instrumented over 90s: ~7,600 presents (~84 fps). So this is not a deadlock, a stall, or a slow-progress problem. It is a readiness predicate that never becomes true, in a process that is otherwise completely healthy.

The silence is the worst part: nothing on stdout, nothing on stderr, no JS error. The only symptom is that the app never exits.

Expected

executeWhenReady fires once the utility layer scene's resources are ready, as it does on Babylon.js in the browser for the same snippet.

Why it is not visible today

On current master this test is masked by an unrelated failure: the same content exhausts the bgfx view counter and throws Error: Too many views after ~18s, which tears the setInterval loop down and produces a fast, if misleading, failure.

With the view-exhaustion fix in #1805 the throw no longer happens, so the underlying hang is exposed. #1805 does not cause this and does not fix it — idx 170 stays excluded there. Filing separately so the readiness bug can be fixed on its own.

Worth checking whether this affects other gizmo / UtilityLayerRenderer content, since nothing about the failure looks specific to BoundingBoxGizmo.

Environment

Win32, D3D11, RelWithDebInfo, base 03c4d965.

[bkaradzic-microsoft]

Root-caused. The readiness predicate was a red herring — the actual bug is timer starvation in JsRuntimeHost, and the fix is BabylonJS/JsRuntimeHost#220.

What's actually happening

TimeoutDispatcher::ThreadFunction re-arms a repeating timeout on the timer thread immediately, before the callback has run on the JS thread. With delay == 0 the re-inserted entry is scheduled at Now(), which is always already due, so the timer thread's wait_until never blocks. It spins and enqueues callbacks onto the JS dispatch queue faster than the JS thread drains them. The queue is unbounded, so it starves everything else on it — including NativeEngine::CreateProgramAsync's shader-compile continuation, which is posted through JsRuntimeScheduler.

So the effects genuinely never become ready, but not because of anything in the readiness logic: their compilation results are sitting in a backlog behind millions of interval callbacks. That is also why compilationError is empty — nothing failed, nothing arrived.

The validation harness drives frames with setInterval(fn) and no delay argument, which is exactly the 0-delay case.

How it was isolated

• An identical trivial scene (no glTF, no network) reaches ready in ~13 ticks under engine.runRenderLoop, and never under setInterval + beginFrame/render/endFrame. The frame driver is the only variable.
• With parallelShaderCompile disabled, all meshes report ready (notReady=0) but executeWhenReady still never fires — which points away from rendering entirely and at a starved setTimeout (Scene._checkIsReady re-polls via setTimeout(…, 100)).
• Confirmed with no Babylon involved at all: a 0-delay setInterval ran 2000 ticks in 759ms while a setTimeout(…, 100) never fired.
• Confirmed it's burial and not loss: clearInterval makes the overdue setTimeout fire 40ms later, 2.4s late.

Result with the fix

• The readiness matrix {setInterval, runRenderLoop} × {parallelShaderCompile on, off} goes from 2 of 4 cells hanging to 4 of 4 ready.
• Validation test idx 170 (Nested BBG) now passes in 2s (0.410% pixel difference, allowed 2.5%), where it previously hung indefinitely.
• Full Playground validation suite: 301/301, unchanged, no timing regressions.

Note that idx 170 needs both this and the view-management work in #1805 — without #1805 it fails with Error: Too many views. Once #220 lands and BabylonNative picks up the new JsRuntimeHost, idx 170 can be un-excluded in Apps/Playground/Scripts/config.json.