Rework how rendering works on the graphics thread

[bghgary]

Currently, the main rendering loop is a polling mechanism. The suggestion is to make this an event-based system and make it easier to use. Will fill in more details later.

Possible ramification:

• Calling Start/FinishRenderingCurrentFrame while nothing is being drawn can cause huge slowdowns in performance. For example, calculation bounding boxes without rendering with the current code will cause the CPU to spike because nothing is stopping the rendering from polling.
• If the JS side of things keep trying to add things to the native render queue without corresponding calls to StartRenderingCurrentFrame/FinishRenderingCurrentFrame, bgfx will run out of views the next time FinishRenderingCurrentFrame is called because all of the draw calls will be bunched up together. There is a related scenario where if the JS side is doing nothing (i.e., not rendering anything), then calling StartRenderingCurrentFrame/FinishRenderingCurrentFrame will also do nothing. If StartRenderingCurrentFrame/FinishRenderingCurrentFrame is being called in a tight loop, which it often is, then this will eat the CPU at 100%.

Also the JS side does not synchronously change bgfx state, it queues a bunch of commands into a buffer and that whole buffer is sent once per frame, and then all that state is applied on the native side to bgfx. This means the JS side could be working on the next frame (populating another command buffer) while the native side is processing the command buffer, setting bgfx state, rendering, etc.

We should also look at what is actually being queued from nativeEngine.ts. Some work may end up out-of-order if they are run immediately instead of queued.

Another problem is:

Setting a breakpoint in JS in Safari with Babylon Native will hang inside a NativeEngine::RequestAnimationFrame callback. It seems if the main thread in Babylon Native is blocked while stopped at a breakpoint in Safari web inspector, the web inspector will hang.

[bkaradzic-microsoft]

In #1652 following issues from here are addressed:

Issue Point	Status	PR
Polling-based main loop → event-based	❌ Not addressed	Main loop still polls (PeekMessage + Finish/Start every iteration). No event-based system.
CPU spike when nothing is being drawn (Start/Finish tight loop with no rendering)	⚠️ Partial	FinishRenderingCurrentFrame now waits on CV for FrameCompletionScope counter, which avoids pure spin. But if no scopes are active, it still calls bgfx::frame() every iteration.
bgfx runs out of views when JS queues without Start/Finish	✅ Fixed	Single encoder model — encoder acquired in Start, ended in Finish. SubmitCommands always acquires FrameCompletionScope which blocks until Start runs. View IDs reset each frame.
JS populating next frame while native processes current	✅ Addressed	Single encoder + FrameCompletionScope gate ensures JS can't use the encoder while bgfx::frame() runs. m_frameBlocked serializes access.
100% CPU when JS idle + tight Start/Finish loop	❌ Not addressed	Same as the polling issue — needs event-based scheduling.
Out-of-order work from nativeEngine.ts	⚠️ Partial	ReadTexture moved out of command stream, blit executes inline with scope. General command stream architecture unchanged.
Safari debugger hang	❌ Not addressed	FrameCompletionScope blocking would still deadlock if JS thread is paused at breakpoint while main thread waits for scopes.