pmndrs
Suggestion: Separate "overriding the render loop" from "renderPriority" in useFrame
Currently when you pass a positive render priority to useFrame the built-in render functionality is disabled and it becomes the components responsibility to render the full scene in addition to whatever else the component wants to do. The issue is that there are plenty of use cases that don't require completely taking over the render loop (screen ui components for example) and there's no way to know if another component has already claimed responsibility for.
This leads to scenarios where end users need to explicitly disable render loop overriding where it shouldn't really be necessary if multiple components are doing so. The 3d tiles renderer project, for example, provides a CompassGizmo that just displays an icon in the bottom right and in no way requires changes to the built in render loop. However because of the requirement that the component also be able to render the full scene due the priority, when another component is added that does the same (like EffectComposer) the components, confusingly, break (unless the user knows to change the override flag).
Suggestion
My suggestion is to separate the logic for cancelling the render loop so renderPriority just changes the order of execution, as the name implies, rather than overloading the field to do both tasks. This can be done by passing an extra argument to useFrame:
useFrame( () => {
/* render stuff after the render to canvas */
}, renderPriority, overrideRenderLoop );
This can be done in a backwards compatible way by defaulting overrideRenderLoop to its current behavior.
@krispya, this is something we have designed for v10, but I don't see mention in #2688.
The proposed fix is more of a bandaid. We could do it, but I would rather complete a robust scheduling API like we mocked up a couple of times and have one migration event instead of multiple.
@CodyJasonBennett
this is something we have designed for v10
If there's a brief write up or anything on how this would work I can take a look to see how it would fit into the components I'm working it.
I’ll see if there is a surviving API doc for React, but the internals are being worked on here: https://github.com/pmndrs/directed
I think there will need to be a robust API redesign that we could work on in the open.