Change timing of when updateRenderState changes apply by toji · Pull Request #1111 · immersive-web/webxr
Fixes #1051. Would love @asajeffrey's input on this!
Apologies that this has taken as long as it has to get a PR up. Doing some GH and meeting minutes archeology, the primary concerns about the algorithm as it currently is written seem to be that Alan needs it to allow for non-blocking communication to the XR hardware and otherwise myself and a couple of others just want to ensure that the timing of when the changes apply is reasonably predictable.
This change moves the apply the pending render state execution to immediately after the frame loop executes, and queues a task to do it. Then it also moves the execution of the frame loop into a task on the same queue, which should implicitly ensure that the render state update must finish before the next frame executes. (I believe that the frame loop execution was effectively taking place in a task before anyway, so this just makes that explicit. Please correct me if I'm wrong!)
This gives us the behavior that any changes will apply some time after the frame finishes executing, but the only guarantee is that they will be finished applying by the time the next frame begins executing. This means the most predictable way to interact with the render state is to inspect and update it within a frame, with the expectation that any changes will take effect in the next frame.
This is technically a backwards-compatibility break, but I have a hard time imagining that any developers are strongly dependent on the current timing.