Chrome VSYNC bugs
July 30, 2016

UPDATE: Chrome has made a LOT of improvements to VSYNC, and VSYNC in Chrome now works very well most of the time, BUT, there are still minor issues and room for improvement, as documented below. Your 'vote' on this bug report will let Google know that continuing to improve VSYNC is still important!

Chrome's 96MB GPU memory limit breaks VSYNC: Run and switch to a 44MP background image, and Chrome is no longer VSYNC aligned. This is most noticeable on Intel integrated graphics systems.

YOUR VOTE CAN HELP GET CHROME FIXED: Visit the master bug for VSYNC issues in Chrome and click on the 'star' in the bug report (if you don't see the star, click on 'Sign in' in the upper right corner of the web page and use your Google sign in):
How to prove to yourself that Chrome's GPU memory limit is the problem: First, verify that Chrome is using the GPU for canvas -- go to "chrome://gpu" and verify that "Canvas" is "Hardware accelerated". Next, go to "chrome://flags", find the "Accelerated 2D canvas" section, click on the "Disable" link (to re-eanble the GPU for canvas, repeat these steps and click on "Enable"):
Then, relaunch Chrome (very important step; do not miss restarting Chrome) and notice that Chrome -- when it does NOT use the GPU for <canvas> -- now PASSES the '44MP' VSYNC test! Google has known about the core issue causing this bug since at least 2013 (Chrome is limited to using 96MB of GPU memory, even if your GPU has 12288MB of memory).

See the 'Bug 464835' section below for more information, and another test...

Other Chrome VSYNC bugs and issues:
  • TWO frame input lag (aka: VSYNCing TWICE): Bug 460919 and Bug 658601: Chrome on Windows has twice the mouse/keyboard/etc input delay that it should -- TWO frames instead of one frame -- because Chrome (via ANGLE) asks DirectX to present rendered frames on VSYNC -- which is the proper present location for an OS that does not composite, but it is the worst possible location for an OS with a Compositing Window Manager (like Windows Aero Glass). The result is an entire extra frame of input delay -- the ANGLE present on VSYNC misses the DWM composition, forcing the frame to wait an entire frame just to be composited:

    With both Chrome and the OS compositing, the end result is that a presented frame must first wait for VSYNC via ANGLE via DirectX, and then after that, the frame must wait for second VSYNC via Windows Aero Glass -- before the rendered frame is shown on the display.

    This bug is now much more noticable since Chrome 54.0.2840.59 (2016/10/12) and Canary 54.0.2817.0 (r409376) on 2016/08/03, that fixed a bug, forcing ANGLE vsync ON more often.
  • 96MB GPU issue: Bug 464835 and Bug 367355: Chrome can not VSYNC when only 96MB of GPU memory is used. Google has ignored this issue since at least 2013 (Bug 305617).
    GPU memory test: Chrome crashes and burns (in an "Aw, Snap!" message) in this simple GPU memory test, whereas all other major web browsers pass the test.

    The core problem is that Chrome has a hard-coded inflexible 96MB GPU memory limit. It does not matter if your GPU has 999MB or 12288MB of memory. Chrome will refuse to use more than 96MB of GPU memory. And the result is visibly devastating -- Chrome comes to a crawl, because it is spending all of its time thrashing GPU memory (trying to do everything via a 96MB window).

    UPDATE 2017/04/26: A 'fix' is pending in 60.0.3082.0 (r467338) -- the 96MB GPU limit was raised to 256MB (a 'temporary mitigation' until a more permanent solution can be found).

    UPDATE 2016/09/29: In Canary 55.0.2875.0 (r421651), the GPU is turned OFF when large images in a <canvas> are detected. This 'fix' works when there is a single large image, but it does not work when many smaller images are referenced.
  • VSYNC accuracy: Bug 467617: How to dramatically improve Chrome VSYNC accuracy, and improve battery life!
    FIX PENDING: 2017/05/10: You can test the prototype of the fix for this (on Win 8.1 or later only) by setting "D3D v-sync" to 'Enabled' in chrome://flags.

    A new way to synchronize to VSYNC without using OS timers (whose use drains the battery faster). Google has a functional prototype working. This should also dramatically improve the 'vsync offset' (how quickly the rAF callback is called after true vsync).

    UPDATE 2017/02/26: You can test the prototype (on Win 8.1 or later only) by running Canary with the --enable-features=D3DVsync command line option.
  • FIXED: GPU memory purge too agressive: Bug 631166: Chrome's 'GPU memory purge' is too agressive, which causes VSYNC failures.
    Fixed for the general public as of 2016/12/01 with release of Chrome 55.0.2883.75. As of 2016/09/22, a fix is pending in 55.0.2869.0 (r420485).
  • FIXED: VSYNC initialization problem: Bug 632785: Chrome had a VSYNC intialization problem in Windows, until the Chrome app window was resized.
    Fixed for the general public as of 2016/10/12 with release of Chrome 54.0.2840.59. As of 2016/08/02, a fix was pending in 54.0.2817.0 (r409376). But this fix changed the input lag from one frame to two frames.
  • FIXED: Incorrect timebase/interval: Chrome used an incorrect timebase and interval for 'internal' VSYNC under Windows.
    Chrome's VSYNC method was hopelessly broken for a while, but no one noticed because that non-functional VSYNC implementation was masked by Chrome also using ANGLE -- where display frames were presented to DirectX, with an option that caused Present() calls to also wait for VSYNC.

    Fixed as of 2014/10/25 in 40.0.2200.0 (r301230). This all changed in Chrome 37 when DirectX vsync was accidentally turned off, caused major jitter, and Bug 422000 was filed, and a correct timebase/interval was then used under Windows.

    Example: As of 2014/02/25 in 35.0.1859.0 (r253077), Chrome used a timebase of 0 and an interval of 16.666 ms (both timebase and interval are incorrect). Tested on a laptop with an actual measured interval of 16.721 ms.