All posts tagged with vsync

VSync and Browsers (lack-of)

March 21, 2018 - Søren Alsbjerg Hørup

While developing my HTML5 game, LaserDefence, I stumbled upon vsync issues in Chrome - specifically that my game stuttered several times throughout the gameplay.

I tracked the issue down to the specific Chrome version installed as standard webview on Android 6.0 and I was able to fix the issue by compiling my HTML5 game using Crosswalk.

However, investigation of the issue showed that all browsers (more or less) have vsync issues. This has also been reported by, a site where one can test a browsers vsync capabilities.

For Chrome on Windows, vsync more or less works - i.e. no dropped frames, however on my Android phone a Galaxy S5 running 6.0 frequently showed dropped frames using Chrome. Other browsers exhibited similar issues.

According to, both Firefox and Chrome implement vsync “wrongly” meaning that dropped frames will happen resulting in stuttering in the gameplay and or animations.

One is met with the following messages when visiting from Firefox and Chrome:

“Firefox is hopelessly broken (timers/vsync/etc) — DO NOT USE!” “Google Chrome has VSYNC issues — You can help get Chrome fixed!”

Funny enough, Edge seem to be the browser which implements vsync properly, but even so, Edge does not support high refresh-rate displays which clearly puts the browser at a disadvantage compared to Chrome and Firefox.

As of 2018, no browser seem to implement proper vsync with high-refresh rate support. VERY disappointing considering that more applications are moved to the web, which includes graphical demanding applications.

Lets hope 2018 is the year where atleast Chrome and Firefox mets the quality test of…

Over- and under-clocking Refresh Rate

January 25, 2018 - Søren Alsbjerg Hørup

Recently I have been working on a HTML5 game using Pixi.js. One issue I have come across when doing web game programming is that it is not possible to disable vsync to test my game with higher and lower FPS.

The window.requestAnimationFrame() fires before the next repaint and is therefore tied to the refresh-rate of the monitor in use. For a 60hz monitor, the function fires every 16.66ms.

One could create a custom interval timer to simulate different refresh rates. This works fairly well, although the update will for obvious reasons be out of sync with the monitor.

Another method is to change the refresh-rate of the monitor using INI patching on Windows or using GPU tools such as NVIDIA Control Panel. A monitor is designed for a specific refresh-rate, where 60hz is the most widely PC monitor refresh rate.

Depending on the monitor, it is sometimes possible to over-clock the monitor yielding higher refresh rate. Similarly, under-clocking can be use to reduce the refresh-rate. For my 60hz DELL 2515h monitor I can increase the refresh-rate to 80hz before the monitor goes blank.

This allows me to test different frame rates, while preserving vsync, when developing HTML5 games. Similarly, I can reduce the frame-rate by under-clocking the monitor to e.g. 50hz or 30hz.

For NVIDIA GPUs, changing refresh-rates can easily be done through the NVIDIA Control Panel:


The Test button will test the refresh rate before adding it to the list. When added, you can select the custom refresh rates from the drop-down menu to the right.

This can be done even when the game is loaded in the browser. A site such as can be used to verify that the refresh rate of monitor is in effect in the browser.