views:

91

answers:

1

In this page that counts the number of frames rendered and prints the FPS onto the canvas, we can see that it tops out at 100fps, which seems suspicious at the least. Why is this?

<!DOCTYPE html>
<html lang="en">
 <head>
  <meta charset="utf-8">
  <title>Canvas FPS artificial limiting</title>
 </head>
 <body>
  <canvas id="c" width="320" height="240"></canvas>
  <script>
   var c = document.getElementById('c').getContext('2d'),
    f = 0,
    s = new Date;
   setInterval(function() {
    c.clearRect(0, 0, 320, 240);
    c.fillText(++f / ( ((+new Date) - s) / 1000 ), 8, 16);
   }, 0);
  </script>
 </body>
</html>

I'm currently having this problem on Firefox 4.0b6 and Ubuntu 10.10 beta.

+9  A: 

I got it! According to this page:

https://developer.mozilla.org/en/window.setTimeout#Minimum_delay_and_timeout_nesting

setTimeout and setInterval are clamped to a minimum of 10ms on Firefox (which is 100 iterations per second) to avoid lock-ups and UI performance degradation. That means, delay values lower than this use 10ms instead (up to 100fps).

This is not a canvas problem; it's artificial limitation of the minimum delay on timers.

Edit: further reading suggests that Chrome does a 4ms clamp, which enables a 250fps artificial limit on timers.

Delan Azabani
That's correct. Also, even 100 FPS is too much for real uses. See this article about APIs for more efficient animation: http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
Nickolay