Seems to depends on framerate and not time ?

[flyingrub]

The simulation works great on my phone but is way to fast on a gtx1080 without vsync.

[PavelDoGreat]

I think all browsers lock framerate to 60. Are you testing it in chrome?

[PavelDoGreat]

Also simulation splat's force differs on different screen resolutions

[flyingrub]

I am on firefox and forced v-sync off, to benchmark shadertoy

[vith]

I think all browsers lock framerate to 60.

This is not the case. I get 240 fps at https://testufo.com/

In WebGL-Fluid-Simulation, the simulation is completely dark about half a second after I stop clicking. I assume it's not supposed to run that fast, as there's little time to observe any details.

[PavelDoGreat]

ok I have to add code that would limit framerate to 60 regardless of screen refresh rate

[Martin-Pitt]

Hmm, I think you should definitely render at screen refresh rate, but you might want to run/adjust the simulation at a different rate. How about using performance.now() / or the time argument you get through the requestAnimationFrame callback.

Otherwise you are not really using hardware to give the user the best experience possible, if they decided to get a good GPU and fast display to enjoy it with.

In the following: https://github.com/PavelDoGreat/WebGL-Fluid-Simulation/blob/d20a9bb69df9816543970c452f030149b5c8cb60/script.js#L969-L978

The MDN example of rAF with the high resolution timestamp argument: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame#Notes

So maybe something like:

update(performance.now());

let start = null;
function update (timestamp) {
    resizeCanvas();
    input();
    if (!config.PAUSED) {
        if (!start) start = timestamp;
        let delta = timestamp - start;
        step(delta / 1000);
    }
    
    render(null);
    requestAnimationFrame(update);
}

Since 2013 Firefox, Chrome and even Edge/IE all have supported rates greater than 60Hz.