Framerate issues at 144hz

[fenomas]

The main point is to pass a fixed value to tick(), rather than the "actual" time between ticks. How you drive the function shouldn't make a big difference. I think the library I'm using actually uses both an interval and a RAF loop, but I haven't looked closely.

 

At a guess, I'd imagine if you use a plain setInterval the actual tick rate be somewhat slower over the long run, and vary a little by browser.

[jerome]

Actually, your implementation is quite elegant because there is only one callback, assuming the render treatment is light and always faster than the logic/tick part.

So one loop only embedding the render and the logic but running each at its own frequency.

Each relative code is decoupled from each other, nice ! 

 

However I don't know if a mechanism with two separated callbacks/loops (render/RAF and logic/Interval) is better (in terms of what ?) althought I think both have quite a similar performance.

 

I like yours 

[jerome]

Note well that in both methods (Fenomas single callback or separates setInterval callback) we set a fixed delay so the logic engine (ie physics) may evolve at its own clocking different from the render clocking... say here 40 ms vs 16 ms

But, because of JS monothreaded process, we know that only one function is run at a given moment.

So if the logical engine treatment lasts almost 40 ms, the render engine will have to wait to display the next frame, it is to say that every 40 ms, at least two 16 ms frames won't be displayed. Not that important ...

 

This just gave me an idea to slice an hypothecal long during logical engine (staying in the single process world, so without web worker here although I truly think they are a good lead). We could imagine to keep on calling the logical engine at a fixed frequency but to get its final result only after it has really finished its computations.

 

Not clear ?

 

Imagine the particle system (or the SPS) as our logical engine and the registerBeforeRender function as the Fenomas RAF function depicted in his former post. Ok ?

If now we try to manage, say, 10 millions particles, what will happen ? (I know we can't build a mesh with 10M vertices, it's just for the example).

Each 40 ms the updateParticles loop will start to iterate from 1 to 10 millions to compute each particle new status and coordinates. This may last some time, nope ?

 

So imagine that, instead of iterating on 10 millions particles, it is called more often but it is said to only compute about 10K new particles each call, and finally only  to update the newly computed mesh to render. Wouldn't it be better ?

 

I'll try to implement a PG example with the SPS, what has a lower performance limit than the BJS PS, so it will be more understandable