You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that Tres set the DPR (see code) completely in autonomy without any way to control that, imho is conceptually wrong for couple of reasons:
The dev should be in charge to decide the DPR or at least be able to clamp. For example if the app is opened on a 3DPR mobile is gonna run at 3, that is completely insane.
The app should not change the dpr on resize without consent. I noticed it because i was setting manually in a range
but on resize switching between monitors on my macbook was set back to 2 due the useDevicePixelRatio hook. This second point tho depends on the first one. If We decide to let the app handle the resize, it's 100% needed to add a clamp on that.
This can lead to some big issues, both perf wise and effect wise. I notice the "issue" because i was doing some effect in screen-space, where my resolution wasn't matching my DPR vec2 st = gl_FragCoord.xy / (gResolution * gDpr);
My take on this is that the library can take care of the DPR but at least give the user some way to control, like they don in r3f where you can set dpr=[low, high] that clamps it :)
hey @alvarosabu /. @andretchen0 saw you took care of this (love) but i think there is still an issue.
Everything works fine because dpr is correctly clamped, although if you try to switch between two monitors with different DPR it changes the DPR of the canvas even without triggering a resize (just move the window between the monitors).
You would think is fine buuut if you are working with screen resolution (so DPR) in a shader this behaviour is kinda odd because you need to update the screen-size there but there is no way to detect is changed without a resize currently.
IMHO solutions are 3
Don't update the DPR without a resize (so you can listen on a resize and update the dpr internally)
I noticed that Tres set the DPR (see code) completely in autonomy without any way to control that, imho is conceptually wrong for couple of reasons:
but on resize switching between monitors on my macbook was set back to 2 due the
useDevicePixelRatio
hook. This second point tho depends on the first one. If We decide to let the app handle the resize, it's 100% needed to add aclamp
on that.This can lead to some big issues, both perf wise and effect wise. I notice the "issue" because i was doing some effect in screen-space, where my resolution wasn't matching my DPR
vec2 st = gl_FragCoord.xy / (gResolution * gDpr);
My take on this is that the library can take care of the DPR but at least give the user some way to control, like they don in
r3f
where you can setdpr=[low, high]
that clamps it :)Reproduction
Steps to reproduce
System Info
Used Package Manager
npm
Code of Conduct
The text was updated successfully, but these errors were encountered: