Chrome VSYNC bugs
July 30, 2016

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 (Windows Aero Glass). The net result is an entire extra frame of delay.
    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 2016/09/29: In Canary 55.0.2875.0 (r421703), the GPU is turned OFF when large images 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!
    A new way to synchronize to VSYNC without using OS timers (whose use drains the battery faster). Google has a functional prototype working. The should dramatically improve the 'timebase' of when the rAF is called back.
  • 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).
  • 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.
  • Incorrect timebase/interval: Chrome used an incorrect timebase and interval for 'internal' VSYNC under Windows. The only reason Chrome was VSYNC'ing correctly at all was because Chrome also presented frames to DirectX, asking DirectX to sync/wait for VSYNC.
    Fixed as of 2014/10/25 in 56.0.2924.87 (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 used under Windows.
    Example: As of 2013/05/14 in 29.0.1508.0 (r200024), Chrome used an interval of 16ms. As of 2014/02/25 in 35.0.1859.0 (r253077), Chrome used a timebase of 0 and an interval of 16.666 ms. Tested on a laptop with a measured interval of 16.721 ms.