New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider how useRenderLoop works. #633
Comments
as stated here #624 (comment) imho have the option to take control of the render-loop entirely and the option to specify the priority are a "must have", as you can do in If you do useFrame(() => {}, 0) you won't see anything because you are taking control over the render loop, very useful when you want to render manually into render-targets or have custom pipeline or render with layers :) |
Also Related
Moving forwardI wonder if we'd be best off simply leaving the current
We could then more or less freely implement a new function that's tied to a particular ... Or maybe we just deprecate |
Hi, @andretchen0 I was doing the same mental exercise yesterday. Let's analyze the pros and cons of the several options I managed to create a render loop per instance of That would be a huge breaking change but, it's actually how R3F Option 1 - Both composables coexist
With this approach, we avoid having a breaking change that would make the Pros
Cons
Option 2 - Deprecate
|
Ideally, I'd like to take some things off the list of cons. I'd prefer to keep the current API intact, while tying it to a API-wise,
Behind the scenes, we'd reimplement the old API –
Yeah, this is the real stumbling block for me, too. It's just really helpful to
It looks to me like rather than throwing here ... https://github.com/Tresjs/tres/blob/main/src/composables/useTresContextProvider/index.ts#L174 ... we could create a new unbound context and bind it when the next That'll work for common use cases, I think. We can offer an explicit API for more control for users who want it. I've been doing some smaller nice-to-haves that I'd been putting off. Once I'm done with that, I'll move back to the core to try to move this forward. In the meantime, I'd prefer not to hold back |
Hi @andretchen0 thanks for your insightful feedback. In the following days I will push the PoC I got working taking in consideration both your feedback and @JaimeTorrealba. Now that this pandora box was opened. Should we bind all composables to each instance or just the loop?
I personally only see benefits on the render loop one, but the rest can be global inmho. It's true that R3F has a warning on the docs that Hooks can only be use inside of the Canvas context |
Ok. Just for reference, I think this discussion has most of the relevant issues related to
Off hand, I'm not sure. I do know that if we're going to have plugins, we need |
@alvarosabu @JaimeTorrealba and I had a chat about the while topic. We propose the following structure for Types/Interfaces: interface Options {
delta: number
elapsed: number
clock: Clock
context: TresContext
}
type EventHookOn = (
fn: (opts: Options) => void,
priority?: number
) => {
off: () => void
}
interface UseLoop {
onBeforeRender: EventHookOn
render: (opts: Options) => void
onAfterRender: EventHookOn
...
} Pros:
|
Description
useRenderLoop
is used to provide the end user a callback methodonLoop
every frame per second to align with the one that the core uses for rendering.It's based on
useRafn
composable from@vueuse/core
https://vueuse.org/core/useRafFn/ but due to the feedback of the community, there are few issues related to its current behavior:useRenderLoop
: render after updates #607useRenderLoop
per page share state #252onLoop
function not called innuxt generate
(SSG) but working in dev mode nuxt#97Suggested solution
Refactor
useRenderLoop
to move away fromuseRafn
Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: