1. Get a display that support 120Hz refresh rates. 2. Visit https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_benchmark/10kCubes.html 3. Observe that the FPS counter rendered on the page says "FPS: 60" Expected: The requestAnimationFrames should be running at 120 fps. For comparison, visiting the same page in current stable Chrome 36 does render the page at 120 fps.

On windows it should do 120 fps by itself. On Linux and OS X you'd have to manually set the preference layout.frame_rate = 120.

Having been through the precise DWM refresh driver on Windows, in the past week, we should be trying to vsync to what ever refresh rate is reported to us via DWM.

I would recommend not closing this as a duplicate of bug 707884, since 60Hz has been so prevalent for so long, and testing a finished implementation of bug 707884 on a non-60Hz display certainly warrants an item of its own.

(In reply to Dan Glastonbury :djg :kamidphish from comment #3) > Having been through the precise DWM refresh driver on Windows, in the past > week, we should be trying to vsync to what ever refresh rate is reported to > us via DWM. We do this for more than a year (bug 856427). Few caveats with current implementation: - Only for windows. - Only synced to the main display (even if the Firefox window is on a secondary one). - It's "soft sync", i.e. we don't block present on vblank, but rather we query the DWM for the last vblank and interval, and use timers to set the next refresh driver iteration slightly after(10% interval) the extrapolated next vblank. requestAnimationFrame is serviced at the refresh driver iteration so it should adhere to whatever frequency the main monitor has (assuming the system is fast enough to push 120 iterations/sec). Hopefully Project silk (bug 987532) will replace this implementation.

(In reply to Avi Halachmi (:avih) from comment #5) > - It's "soft sync", i.e. we don't block present on vblank, but rather we > query the DWM for the last vblank and interval, and use timers to set the > next refresh driver iteration slightly after(10% interval) the extrapolated > next vblank. I don't think this is a bad thing. If you try to actually present during VBlank while the DWM is active, you can end up racing with the compositor. I know compositors on some OSes specifically misreport when VBlank happens to allow you to do this, but Windows' DWM isn't one of them. The easiest way to synchronize with the DWM is to present, then DwmFlush() (which returns after the next composition).

It is bad from for at least the following: - We lose 10% of the vblank interval. I.e. if everything goes according to plan, then we're starting the iteration 10% interval after vblank. This leaves us 10% less time to complete the work for this iteration and present on time. If the load is low then it's not an issue, but if the load is high, then we're allowing roughly 10% less load than we theoretically could. - The timers are not accurate enough, and are integers (in ms). On top of that they're channeled via the event loop which could be loaded (although timer events do get some priority over other events). - On top of that (though unrelated to the vsync implementation which just sets the timer value according to the DWM info instead of some virtual 60hz signal), the timer to the next iteration is set before the current iteration starts, so if it sets a timeout of 17ms but the current iteration happens to take 20, the next iteration might take precedence over some events waiting at the queue (such as input events) possibly resulting in unresponsiveness. Regardless though, project silk would hopefully take care of all those issues properly (accurate events, sync the compositor and the refresh driver, etc).