Does the requestAnimationFrame always get disabled before 60 FPS?
requestAnimationFrame
called whenever the screen is ready to be redrawn. On modern screens, refresh rates can be well above 60 frames per second. If there is a lot going on in these calls, it can affect the overall performance of the application.
So my question is, should it requestAnimationFrame
shrink to 60FPS? Can the human eye actually tell the difference between, for example, 16ms and the reissue latency of 8ms?
[UPDATE] I ended up reducing it to 60FPS for better performance on high refresh rate screens. And would suggest this approach to anyone with a lot of stuff going inside rAF calls. Of course, you have to do the testing yourself.
source to share
Per MDN it doesn't have to be 60 FPS.
Relevant quote:
This would require calling the animation function before the browser does the next redraw. The number of callbacks is typically 60 times per second, but usually matches the display refresh rate in most web browsers, as recommended by the W3C . Callback speed can be reduced to a lower speed when working on background tabs.
As for can, the human eye distinguishes 60 versus 120 FPS, which is an open and stubborn question. Some argue that they see it, others argue that it is impossible. Letting the end user choose (or just use their hardware to its fullest) is probably best.
As noted by markE's comment . The callback requestAnimationFrame
receives DOMHighResTimeStamp
which is a high precision timer accurate to the thousandth of a millisecond. "Using this timestamp and calculating the delta between frames, you can adjust the refresh rate to whatever you want.
Literature:
Note: Please be sure to leave a comment when referring to any downvotes, otherwise they will not be useful feedback.
source to share
My guess is that people with 120-hour or higher frame rates know that it takes more resources to create twice as many frames.
They are and / or they have more powerful computers than most users. I personally have a very powerful PC, but two 60Hz monitors, and the only guy I know who has a display with a higher frame rate than 60Hz is a pro player, so obviously he has no problem with performance while browsing the web.
Also, people using very high frame rates get used to this level of turnover and they may notice the difference (event if I doubt it).
My two cents: respect their preference for having an overflow display. This is what they want.
source to share
By default, I think it is good to limit the frame rate to 60Hz, since:
• A high frame rate means more heat, so the fan (cpu) noise will be annoying.
• For most games, nobody will notice.
• it's easy to do.
• For those with environmental concerns, high fps consumes more power (==> more CO2).
About 120Hz visual interest:
For 2D games where only a tiny amount of screen actually changes between each frame, it is of little interest.
For 3D games, especially those aimed at realism, using 120Hz allows for a more "cinematic experience". Why?
==> Most 3D renders only render the scene at a specific point in time, so what you see is a sequence of "perfect" stills.
On the other hand, a real camera will, like the human eye, remain open for a few milliseconds, so the movements that occur during this time will leave a mark on the image, providing a more faithful life experience.
The 60Hz border is enough to fool the eye about motion, so what the 120Hz + screen brings is that the screen is so fast it can't follow it and you have the camera / eye trail effect again.
The code looks like this:
var minFrame = 13;
var maxFrame = 19;
var typicalFrame = 16;
var gameTime = 0;
var lastDrawTime = -1;
animate(drawTime) {
requestAnimationFrame(animate);
var dt = drawTime - lastDrawTime;
lastDrawTime = drawTime ;
if (dt<minFrame) return;
if (dt>maxFrame) dt=typicalFrame; // in case of a tab-out
gameTime+=dt;
// ...
}
function lauchAnimation() {
requestAnimationFrame ( function(t) { lastDrawTime = t;
requestAnimationFrame(animate); } );
}
Rq1: When you limit fps, you have to take care that the frame rate in the browser is generally unstable.
So even if the app is not doing anything, a 60Hz screen has a frame duration that can go anywhere from 14ms to 19ms. (!!!!) So you have to take some headroom when limiting the frame rate to some value.
Rq2: In the above example, "TypicalFrame" should be replaced by the native frame rate of the screen (which you have to calculate yourself).
source to share