No, for a project I am working on using three.js with requestAnimationFrame, it is capped at the refresh rate the monitor is running on.
So my gaming monitor running 144hz at 1080p runs the application at 144 FPS according to my FPS counter from stats.js[0]
On my laptop running at 60hz it's capped at 60 FPS.
There is a huge difference in the "smooth-ness" as well as reduced input lag on the 144hz vs 60hz monitors. So much that I currently dislike working on the app on <100hz monitors.
I don't know the answer to that. I imagine different browsers/OSes will have different caps.
However, assuming the cap is an issue, I still strongly doubt that with `setInterval` you'll be able to get the precision you need to target specific monitor refresh rates, even if you can figure out a way to detect what the refresh rate is. Maybe if you're targeting Electron, but even there I kind of doubt it. Even with frame caps, `requestAnimationFrame` is still likely the best bet (opinion me).
The reality of games on the web is that timing in general, whether it be for update logic, rendering, or audio is kind of a massive pain, and you'll always be accepting some compromises. To me, those compromises aren't big enough to outweigh some of the other substantial benefits, but I don't want to pretend those compromises don't exist.
Are you on Linux with an Nvidia GPU? I fixed that bug recently. https://crbug.com/535392 On other platforms requestAnimationFrame has been synced to the monitor for a long time, in Chrome at least.
