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
We recently added the three Timer class by Mugen. After this @vanruesc made us aware that he has a modified version inside of pmndrs/postprocessing that can be found here. I'm thinking we should use the same Timer class as pmndrs/postprocessing so that a shared timer is possible between pmndrs libraries.
Notable differences are using getters instead of get functions, reset properly resets the whole timer, autoReset manages the timer with page visibility without constructor side effects and the rAF timestamp can be passed into update (though this optimization was added to the three Timer recently).
The only downside I see is when the three Timer gets merged its API will likely be different from ours. However, I think if we do extend what looks like a better Timer design it can influence the final API and allow us to experiment with new ideas.
The text was updated successfully, but these errors were encountered:
@vanruesc How do you feel about including your Timer class in three-stdlib and centrally maintaining it here? We can use the same class in R3F and possibly sync clocks with postprocessing.
Adding three-stdlib as a dependency in pmndrs/postprocessing for a single class that will eventually be replaced seems overkill to me. I hope the Timer gets included in three soon, even if the API ends up being different.
We recently added the three
Timer
class by Mugen. After this @vanruesc made us aware that he has a modified version inside of pmndrs/postprocessing that can be found here. I'm thinking we should use the sameTimer
class as pmndrs/postprocessing so that a shared timer is possible between pmndrs libraries.Notable differences are using getters instead of get functions, reset properly resets the whole timer,
autoReset
manages the timer with page visibility without constructor side effects and the rAF timestamp can be passed intoupdate
(though this optimization was added to the threeTimer
recently).The only downside I see is when the three
Timer
gets merged its API will likely be different from ours. However, I think if we do extend what looks like a betterTimer
design it can influence the final API and allow us to experiment with new ideas.The text was updated successfully, but these errors were encountered: