Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 606 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Available
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
Chrome fails some tests
Reported by, Oct 9 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36

Steps to reproduce the problem:
1. Visit
2. wait for one iteration of the animation for the test to 'settle down'

What is the expected behavior?
The animation should be perfectly smooth (and is under Chrome 37 and IE).  The 'animation' is so incredibly small that there is no reason for Chrome to drop rendered frames.

What went wrong?
After Chrome 38 was release a couple of days ago, my canvas animations all of a sudden started to show significant jerks and pauses in them.

Internal monitoring showed that the requestAnimationCallback was being called 'on time', and that the animation callback was returning in less than 1ms.

Monitoring via "chrome://tracing" showed inconsistent timing between successive GLES2DecoderImpl::HandlePostSubBufferCHROMIUM calls -- enough so that the likely culprit was dropped frames (two rendered frames placed into one vsync GPU frame).

After creating a very minimal test (jerky3.html above) that replicated the problem under Chrome 38 (Chrome 37 and IE render smooth), running Chrome 38 with the "--disable-gpu-vsync" command line option caused all jerks to go away (and the frame rate to jump to over 300FPS; See 'FPS counter' under chrome://flags).

Clearly, if Chrome can display 300FPS smoothly, it should be able to very easily display a much slower 60FPS with no jerks -- provided it can properly synchronize with vsync.

It appears that Chrome 38 busts vsync" and is causing multiple rendered animation frames to sometimes be 'put' to the GPU within one vsync frame -- which causes very noticeable jerks in <canvas> animations.

Did this work before? Yes Chrome 37

Chrome version: 38.0.2125.101  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 15.0 r0

The problem appears more pronounced on older GPU hardware.
Comment 1 by, Oct 12 2014
I have just confirmed that Chrome's requestAnimationFrame() is **NOT** synchronized to the monitor vsync interval under Windows.

On my computer, my monitor is refreshed at 59.8Hz.  Internet Explorer correctly call backs requestAnimationFrame() at 59.8Hz.  However, Chrome INCORRECTLY calls back requestAnimationFrame() at 60Hz.

That is enough of a difference for Chrome to cause significant jitter/stutter/jerkiness on a regular periodic basis as the two frequencies interfere with each other over time.
Comment 2 by, Oct 13 2014
The test at has been updated to include a very obvious 'visual indicator' when there is no VSYNC synchronization.  Chrome fails the test.

Chrome is able to easily generate hundreds of frames per second (plenty of CPU/GPU headroom).  But Chrome is unable to generate 60 frames per second AND SYNCHRONIZE those frames with the monitor's VSYNC refresh rate.

The result is very jerky animations.
Labels: Cr-Internals-GPU-Scheduling
Brandon, do you think this could be related to your recent multi-monitor changes?
It sounds like something that could be related, but I actually doubt that's the cause. The problem is reported against Chrome 38, which is way too early for my vsync changes to have gotten in unless they were cherry-picked without notifying me.

Even if the changes were in these builds, they will only take effect if the DWM is disabled (ie: the user is using a non-Areo theme in Windows 7/Vista. Will never take effect in Win 8.) If those conditions were met then you may get 60hz instead of 59.8, since the API being used to get per-screen sync rates (EnumDisplaySettings) is only capable of reporting integer values for cycles-per-second.
Comment 5 by, Oct 13 2014
More info: See, which under Chrome 37 reports the correct VSYNC Hz for my computer (59.8'ish), but reports 60.0024Hz for Chrome 38 and Canary (Chrome 40), which is just 1000 divided by the familiar constant 16.666.
Something that just occurred to me: jerryj@, are you using the "Windows 7 Basic" or "Windows Classic" themes? I don't know why the behavior would have changed with Chrome 38, but with the current code using those themes would prevent being able to query the higher resolution refresh interval and it would probably report 60hz instead of the desired ~59.8.
Comment 7 by, Oct 13 2014
#6/bajones@: No, using Aero on Windows 7 (so the window desktop manager is active).  The problem with Chrome 38 was also replicated on a Windows 8.1 machine (where Aero is 'always on').

The issue of Chrome 37 working much better was only tested on Win7 (I do not have Chrome 37 on Win8).

To test the "higher resolution refresh interval" issue: On Win7/Chrome37: exited chrome, changed to "Windows 7 Basic" theme, started Chrome, and the vsync.html test reported the correct ~59.8Hz.  Rebooted.  Ran Chrome and vsync.html and got ~59.8Hz again.
Oddly I am using a current gen macbook pro with 2 monitors plugged in. On one monitor (the main one) canvas content runs at a smooth as butter 60 fps. When I drag the window to my other monitor the content goes all jerky. 
Comment 9 by, Oct 15 2014
I believe I have just found a large clue as to the underlying problem...

Chrome 37: Uses a Hz of 59.8 for a computer with a known VSYNC of 59.8

Chrome 38: Uses a Hz of 60.0 for a computer with a known VSYNC of 59.8
Chrome 38: Uses a Hz of 60.0 for a computer with a known VSYNC of 60.1
Chrome 38: Uses a Hz of 40.0 for a computer with a known VSYNC of 40.06

See the pattern?  Chrome 37 is able to use non-integer Hz values.  Whereas Chrome 38 apparently changed that and can only deal with integer hertz values.  That is a bug/regression.

This also points out the problem that Chrome 38 is apparently only attempting to match the VSYNC frequency, and is not aligning the beginning of animation frames with the beginning of VSYNC periods.
@brianderson: I have found the problems in the source code.  Please have the appropriate individual review (hopefully my analysis below is correct) and implement the fixes.  It would be nice to see a fix get into the next Canary -- is that possible?


about:tracing on my computer showed lot of "DWMVSyncProvider::GetVSyncParameters" and "OutputSurface::CommitVSyncParameters" of {"timebase":0.0,"interval":0.016666}.  However, both a timebase of zero and the interval of 0.016666 are NOT correct for my computer, and (hopefully) the cause of all the screen flickering I am seeing with <canvas> animations.


TIMEBASE: The 'timebase' of zero is a problem because that means that rendering in Chrome is NOT aligned to the beginning of the VSYNC period, but that is incredibly easy to fix.  The cause is a call to "gfx::FrameTime::TimestampsAreHighRes()" here:

which ALWAYS returns false:

The comment in the code contains the fix for this (change "false" to "base::TimeTicks::IsHighResNowFastAndReliable()"), and refers to bug 315334, which was fixed Dec 9, 2013.  Somehow, when bug 315334 was fixed, the fix to not always return "false" in gfx::FrameTime::TimestampsAreHighRes() was missed?


INTERVAL: The issue of "interval" being 0.016666 is a little more interesting.  If we presume that the call to DwmGetCompositionTimingInfo() works:

that would mean that the calculation of the "interval" here:

is actually computing 16666 from timing_info.rateRefresh.

So I wrote a quick Windows app that calls DwmGetCompositionTimingInfo(), and outputs rateRefresh, and the results for "rateRefresh" for me: uiDenominator=1, uiNumerator=60.  Microsoft documents "rateRefresh" as "The monitor refresh rate".  But based upon these results, "rateRefresh" now appears nothing more than a human readable 'idealized' refresh rate (for my Intel HD Graphics 3000, latest driver), rather than the actual refresh rate.

However, the very next DWM_TIMING_INFO structure item is "qpcRefreshPeriod" -- documented as "The monitor refresh period", which in my test program, was FAR more accurate to the known refresh rate.  But please note that qpcRefreshPeriod is NOT a constant, but rather changes (slightly) from call to call, strongly suggesting that it is based upon actual measurement.  I changed my test code to spin wait for DWM_TIMING_INFO "qpcVBlank" to change, and then output "qpcVBlank" and "qpcRefreshPeriod", which confirms that "qpcRefreshPeriod" is simply be the difference between the current and previous "qpcVBlank" times (the "interval" column is just "qpcRefreshPeriod" converted to microseconds):

  qpcVBlank     qpcRefreshPeriod  interval
  ============  ================  ========
  343869541080             32586     16721
  343871300724             32586     16721
  343871333207             32584     16720
  343871365792             32585     16720
  343871398378             32586     16721
  343871430964             32586     16721
  343871463547             32584     16720
  343871496123             32576     16716
  343871528709             32586     16721
  343871561293             32584     16720

Using (and Internet Explorer; known to work), the VSYNC interval for my PC is known to be 16.72136ms, hopefully validating that an "interval" computation based upon "qpcRefreshPeriod" is much better than one based upon "rateRefresh".

Based upon this information, Chrome's "interval" calculation should be changed from using "rateRefresh" to "qpcRefreshPeriod", similar to this:

  interval = gfx::FrameTime::FromQPCValue(static_cast<LONGLONG>(timing_info.qpcRefreshPeriod));


THE NEW MONITOR CODE WILL CAUSE PROBLEMS:  I have another computer with a known Hz of 60.1.  The concern is that the new monitor code here:

will cause problems since dmDisplayFrequency is once again an 'idealized' Hz value (an integer), instead of an accurate measured Hz.  Namely, for a computer with a meausred/real Hz of 60.1, but a EnumDisplaySettings dmDisplayFrequency of 60, the new monitor code WILL (improperly) override 60.1 with a value of 60:


Hopefully, having Chrome compute an accurate "timebase" and "interval" will help to resolve much of the jerkiness that I am seeing???   But I do have some strong reservations.  Because this code (referenced above) I believe was the same between Chrome 37 and Chrome 38, and something else must have changed 37->38 to cause the significant new jerkiness that I am seeing.  Looking at traces, the rate of frame production in the front end was always rock solid.  But looking at traces in the back end (GPU process), suggests that there is something there causing significant jitter in the rate at which frames are being sent to the display.

Hopefully an accurate timebase in the front end will make up for jitter in the back end?  But that back-end jitter is something that you should monitor/trace.


FYI: It would sure be nice to get 'tracing' of "timebase" and "interval" after the calls to DwmGetCompositionTimingInfo() and GetMonitorInfo() here:

Actually, the code regarding setting timebase only with high res timestamps needs to be code reviewed again.


        // If FrameTime is not high resolution, we do not want to translate the
        // QPC value provided by DWM into the low-resolution timebase, which
        // would be error prone and jittery. As a fallback, we assume the
        // timebase is zero.
        if (gfx::FrameTime::TimestampsAreHighRes()) {
          timebase = gfx::FrameTime::FromQPCValue(

because the comments above the 'if' statement don't look right.  Because the conversion of a QPC value to a TimeTicks value is precise (to the microsecond) regardless of the accuracy of the underlying TimeTicks (to the millisecond or sub-millisecond for 'high res' time).  See:

The only difference between the jitter with timebase zero, vs the jitter with a real accurate timebase, is that the jitter is phase shifted into some RANDOM point within the VSYNC interval when a timebase of zero is used.  That random shift is bad.

Instead, the real timebase, if available, should ALWAYS be used, which will result in any jitter being phase shifted to the beginning of the VSYNC interval (much more desirable) -- meaning that the "if" statement for "gfx::FrameTime::TimestampsAreHighRes" above can just be deleted, and just always set timebase from qpcVBlank.  ???

Comment 12 by, Oct 20 2014
Why did our benchmarks not show this?
Re#12: We'll need to take a look at the traces when the regression was introduced, but I suspect the combination of the following: 1) we run with vsync disabled in most Windows configurations so we don't get back pressure if we produce too fast and 2) our test measurements never take into account actual display time, just draw or swap time.

Assigning to Brandon since he kindly volunteered and is familiar with the code in question.
Note that any requestAnimationFrame based measurement will also not take display time into account, so it can't provide a ground truth. Can we query the actual frame display time on Windows somehow?
This issue/bug is about WINDOWS (I have not tested on other platforms).  So here is a quick video so that those of you not on Windows can visually see what I am seeing:

top web browser: Chrome 38.0.2125.104 m
bottom web browser: IE 10.0.9200.17116 update 10.0.21

In Chrome38: The performance graph proves that all 60FPS are being rendered.  But the red/cyan color of the word 'FAIL' proves that NOT all rendered frames made is successfully to a unique VSYNC interval on the display.

In IE: The performance graph proves that all 59.8FPS are being rendered AND the gray color of the word 'FAIL' proves that all rendered frames make it to a unique VSYNC interval on the display.  The delay in calling the rAF callback back appears to be an optimization on IE's part based upon it knowing that the rAF callback is very fast, because when 'Odd Frame Delay' is checked (adding overhead), the delay in calling the rAF callback goes away.

Issue 421235 has been merged into this issue.
Everyone, the jerkiness seen in this issue is nothing more than the effects of an interference pattern between two frequencies.

The jerkiness in Chrome in the video in #15 is FULLY explained by this interference pattern.  Those of you working on this code need to understand how what appears on the surface to be an inconsequentially small frequency difference, actually has a profound effect in a VERY short period of time.  So here goes...

The Hz of my display is known to be around 59.8028Hz (displayhz).  Chrome currently obtains a Hz of 60 from DwmGetCompositionTimingInfo() and computes an interval of 16.666ms, which results in a Hz of 60.0024 (chromehz) being used.

So, if we have a process that does something on a regular basis on each 'tick' of each Hz, at which point will the two frequencies interfere with each other?  Simplistically, the answer is every 1/abs(displayhz-chromehz) seconds.  So, for the actual Hz above, the answer is 1/abs(59.8028-60.0024) seconds, or 5.01 seconds -- Now, review the video in #15, and count the number of seconds between the start of each failure in Chrome and you get 5 seconds!  [as validation, on a second PC with a different Hz, the interference pattern repeated every 10 seconds, and matched calculations].

The more complicated answer is that the duration of the failure (or interference) is the result of the variance at which Chrome wakes up and calls the rAF callback (and an unknown variance in the back end gpu process).  Under Windows, the rAF callback accuracy is strongly impacted by the accuracy of the OS Sleep() function, which Chrome actually controls via calls to timeBeginPeriod().  So under Chrome, that variance is normally under 1ms, but can be as large as 4ms when a notebook is on battery power (these two ms ‘constants’ come from the Chrome source code).

Based upon this, if Chrome can only wake up ‘as soon as possible’ (even if that is several milliseconds) after the true vsync period, and call rAF, the interference pattern will ‘go away’ – and all jerkiness seen in Chrome, will also ‘go away’...

Jerry, would you be able to provide the files needed to run locally? It's proved to be a good test for visually catching the framerate anomalies, but the server it's hosted on is really painfully slow. It's made bisecting and testing this issue fairly time consuming.

See jerky3.html and vsync.html in the attached...
2.2 MB Download
Doing a bisect on the official builds gives my this CL range, which is pretty wide:

The Chromium bisect is much narrower, but doesn't have anything super suspicious:

The ANGLE roll is the most obvious candidate, so I'll start looking there. 
bajones@, someone on a Mac sent me a screen snapshot from tracing, and referenced vertical red hairlines, saying they the vsync times.  Under Windows, I don't see those.  Am I missing something, or those Mac specific, or after "timebase" is non-zero after your fixes, will those hairlines appear?
bajones, regarding the comment in #9 about Chrome37 updating at a rate of 59.8Hz for me, I just ran the test again, and sometimes get 60.002 -- so something crazy is going on.  I will see if I can figure out the conditions that cause the test to behave one way vs the other.

However, from Chrome 37.0.2062.124 to Chrome 38.0.2125.101, there was one very significant change under Windows that may be affecting things?  base::TimeTicks::Now was changed from 1ms accuracy to 1us accuracy (high res time enabled).
Okay, ignore the bisect ranges in #20, after double checking them they actually missed the breaking revision. (This is a REALLY SUBTLE thing to consistently catch across a few dozen browser runs...)

Redid the bisect today and I believe this range to be more accurate:

Includes this little gem:
"Disable Vsync when Aero Glass is enabled."

Now, I'm no Sherlock Holmes, but something tells me that this just might be the regression we're looking for...
Status: Assigned
Comment 25 Deleted
So swapping buffers automatically behind the scenes syncs with vsync?  If so, doesn't that make setting a correct vsync "timebase" to something valid, instead of zero (see #10) all the more important?  [note: prior comment was deleted: I messed up frame timebase with vsync timebase]
As per comments on rev 272724 "The patch improves WebGL performance by up to 20% on D3D11 by avoiding duplicate vsync".  The key word appears to be "duplicate".

If the first vsync code (DWMVSyncProvide, and now WinVSyncProvider) never worked properly in the first place (comment #10), that non-functioning first vsync code would be totally masked by the second vsync (swap buffers) code working.  So when the second vsync was removed, the first had to work (but did not).  If that reasoning is correct, that now explains everything.

Hopefully the fix to this regression is just to fix the first vsync code (see comment #10), keeping patch 272724 in place for the performance boost?

Comment 28 by Deleted ...@, Oct 23 2014
> #23 bajones (This is a REALLY SUBTLE thing to consistently catch..)

Then use this alternate testing procedure, which will consistently produce more YES/NO results...

1. Run the provided vsync.html.  This will accurately tell you at what Hz rAF is being called back -- and no PC I have tested so far uses 60.00 Hz exactly.  But when Chrome is broken, is uses 60.00Hz, which is confirmation that Chrome is broken.  Otherwise it should perfectly match the known Hz of your monitor (run vsync.html with IE or Firefox to see what that is; and if you need a way to absolutely verify the Hz (that IE/Firefox is correct), just ask, I can provide another test the will prove Hz results to you).  For my PC, with a known Hz of 59.802, after running vsync.html, I can tell within seconds if Chrome is busted or working.

2. Review Chrome tracing output.  Look for "OutputSurface::CommitVSyncParameters" and confirm that the "timebase" is nonzero, that "interval" matches the known interval of VSYNC on your PC, and that "timebase" is (mostly) stepping at that interval rate.

3. Finally, use jerky3.html as a final visual confirmation.

Note that results from (1) can easily be tested via automated scripts.

For the record, we have a fix for this that's in the process of being reviewed:
Project Member Comment 30 by, Oct 24 2014
The following revision refers to this bug:

commit 10b6709e59abc1ef5d3921a38b93acd73a689be8
Author: bajones <>
Date: Fri Oct 24 23:48:14 2014

Get high resolution frame timebase and interval on compatible systems

Significantly reduces stuttering of animations on Windows caused by rounding errors in the computation of the display refresh rate.
Also made a minor change to how multi-monitor display rates are handled. Now we only use the value from EnumDisplaySettings if DWM compositing is disabled, even if the monitor refresh rate is lower. The previous logic may have erroniously overridden a display refresh of ~60.1Hz or similar with a less accurate 60Hz.


Review URL:

Cr-Commit-Position: refs/heads/master@{#301230}


Status: Fixed
Comment 32 by, Oct 25 2014
Canary 40.0.2201.2 now produces the correct Hz for my display when viewing vsync.html.  But viewing jerky3.html is now much worse.  The "synchroninzed indicator" now flashes FAIL all of the time, instead of on a periodic basis.  Hopefully all caused by something else that is being worked on that will be fixed before final release?

That's unfortunate to hear. Every system I tested it on performed better with your jerky3.html test, but obviously I can't account for every system configuration. 

Could you visit about:gpu on the system that was performing poorly for you and attach the contents of that page here?
I too still have problems even with Canary 40.0.2201.2. I can still sometime see jerky fps in this example site:

For information, my specs:

Processor: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
RAM: 8,00 GB
GPU: Intel(R) HD Graphics 4000 / GeForce GTX 660m

Maybe this is caused by the dual gpu? I already set all apps to run through the dedicated GPU. But I get the feeling it's not working correctly. chrome://gpu/ tells it uses the internal one, while the Nvidia Panel says it runs through the dedicated GPU. 

Well, I also see more jerkier behavior than before with 40.0.2202.0 on jerky3.htm especially when "Odd frame delay" is checked

CPU: Intel i7 2600k
GPU: Nvidia GTX 660 Ti

Also, when scrolling - either moving the sidebar, or middle button scrolling, I am getting the cyan/red indicator far more often than in static state.

My about:gpu content:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Disabled
Rasterization: Software only, hardware acceleration unavailable
Threaded Rasterization: Enabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
Driver Bug Workarounds
Problems Detected
GPU rasterization is blacklisted on non-Android: 362779
Disabled Features: gpu_rasterization
Always call glUseProgram after a successful link to avoid a driver bug: 349137
Applied Workarounds: use_current_program_after_successful_link
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
TexSubImage2D() is faster for full uploads on ANGLE
Applied Workarounds: texsubimage2d_faster_than_teximage2d
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Raster is using a single thread.
Disabled Features: multiple_raster_threads
Version Information
Data exported	27.10.2014, 18:59:19
Chrome version	Chrome/40.0.2202.0
Operating system	Windows NT 6.3
Software rendering list version	9.11
Driver bug list version	7.7
ANGLE commit id	d2f756be4fd1
2D graphics backend	Skia
Command Line Args	SxS\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Performance Information
Graphics	8.3
Gaming	8.3
Overall	8.1
Driver Information
Initialization time	29
Sandboxed	false
GPU0	VENDOR = 0x10de, DEVICE= 0x1183
Optimus	false
AMD switchable	false
Desktop compositing	Aero Glass
Driver vendor	NVIDIA
Driver version
Driver date	10-16-2014
Pixel shader version	5.0
Vertex shader version	5.0
Machine model name	
Machine model version	
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (NVIDIA GeForce GTX 660 Ti Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 2.1.d2f756be4fd1)
GL_EXTENSIONS	GL_OES_element_index_uint GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_NV_pixel_buffer_object GL_OES_mapbuffer GL_EXT_map_buffer_range GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_float GL_OES_texture_float_linear GL_EXT_texture_rg GL_EXT_texture_compression_dxt1 GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_sRGB GL_ANGLE_depth_texture GL_EXT_texture_storage GL_OES_texture_npot GL_EXT_draw_buffers GL_EXT_texture_filter_anisotropic GL_EXT_occlusion_query_boolean GL_NV_fence GL_EXT_robustness GL_EXT_blend_minmax GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_pack_reverse_row_order GL_OES_standard_derivatives GL_EXT_shader_texture_lod GL_EXT_frag_depth GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source
Window system binding vendor	Google Inc. (adapter LUID: 0000000000008072)
Window system binding version	1.4 (ANGLE 2.1.d2f756be4fd1)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	11
dwHeight	1080
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1920
iAdapter	0
lDriverSize	19966856
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	GeForce GTX 660 Ti
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Integrated RAMDAC
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C ModeVC1_C ModeWMV9_C
szDescription	NVIDIA GeForce GTX 660 Ti
szDeviceId	0x1183
szDeviceIdentifier	{D7B71E3E-52C3-11CF-8866-5B151CC2C435}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	4037 MB
szDisplayMemoryLocalized	4037 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (60Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (60Hz)
szDriverAttributes	Final Retail
szDriverDateEnglish	10/16/2014 18:54:03
szDriverDateLocalized	10/16/2014 6:54:03 PM
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.3
szDriverModelLocalized	WDDM 1.3
szDriverName	nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
szDriverNodeStrongName	oem25.inf:0f066de34a948e92:Section037:\ven_10de&dev_1183
szDriverVersion	9.18.0013.4448
szKeyDeviceID	Enum\PCI\VEN_10DE&DEV_1183&SUBSYS_35561458&REV_A1
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{F711DCAB-7405-4A92-AF50-0EB1C67DC3BE}\0000
szManufacturer	NVIDIA
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorName	Dell U2311H(Digital)
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00DA2001
szRevisionId	0x00A1
szSubSysId	0x35561458
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x10DE
Log Messages
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
bajones, see attached for gpu output from system running the latest canary.

I have two identical laptop systems, and sadly, the one still on Chrome37 just auto-updated to Chrome38.  I see the 'program files' folder still have the 37 version, is there any way to force Chrome to run that version?  Chrome 37 runs these tests much better -- very smooth.

So, on the same hardware, Chrome37 worked great, but Canary with the fix is actually now far worse (janky all the time) than Chrome 38 (janky on a periodic basis).

I have another laptop that is a couple of months old and Chrome37 was always rock solid on that.  Under latest Canary, it also shows the same results (vsync.html Hz now fixed / spot on; jerky3.html always janky).

It would sure be nice to see the red vsync hairlines in tracing output (see comment #21) under Windows.

1010 KB Download
Labels: Needs-Feedback
Tested this issue on Windows7 using: 40.0.2202.3  with below steps:

1. Opened
2. Observed FAIL in Red colored some times.

Could you please confirm the behavior and provide more TESTS to verify this issue. 
Attaching screen-cast & chrome:// gpu used in commnet38#
1.4 MB Download
83.9 KB View Download
Here is the trace info:
Still getting it in canary 40.0.2202.3. It seems the jerky3 test runs better now but I can still observe this in more complex projects like games. FPS Meter shows 60 fps while you can observe jerky scrolling.
There must be something going on with "CrGpuMain" (or some synchronization issue that is causing CrGpuMain to stall).  See attached.

The "Compositor" is waking up every frame (red lines).  The JavaScript rAF callback is called and returns immediately (blue boxes "CrRenderMain"), and yet for some reason, "CrGpuMain" does not finish in time (thick red arrow).
209 KB View Download
OK, this is just crazy -- I can eliminate Chrome jankiness by implementing requestAnimationFrame myself IN JAVASCRIPT -- now THAT is just not right (that I can do in JavaScript what Chrome can not do in native code)!  This bug report needs to be 'reopened' (it is not 'fixed').

How I did it: First, turned off Aero, because I wanted to see the tear line on the screen (an important confirmation of correct Hz).  Then modified jerky3.html to replace all the rAF code with my own setInterval() based code (search the jerky3.html HTML for 'hack') that attempts to create exactly 59.802Hz (a number for my display).  setInterval() is not accurate enough, so I create an accurate interval by getting called back frequently, testing time, and when close enough, spin-waiting to the correct time -- which does result in a super accurate rAF callback at a precise 59.802Hz.

Because the Hz of my rAF now precisely matches the Hz of my display, there is a tear line somewhere within my display.  I just need to 'refresh' the web page, which will randomly position the tear line somewhere else -- I do this a couple of times until I get the tear line where I want it (NOT under the vsync synchronization indicator, and preferably in the middle of the screen).  The end result is a "vsync synchronization indicator" that works (seeing a red FAIL is very rare).  And when I look at about://tracing for my rAF implementation, CrGpuMain has NO iterations that 'run too long' [see attached "crgpumain-with-my-raf-implementation.jpg"].

I then (still with Aero off), switch back to Chrome's rAF implementation, and the "vsync synchronization" indicator starts failing, a LOT.  Now some of this clearly could be because Chrome is now using 60Hz instead of 59.8Hz -- but when I again go into about://tracing, I can see that CrGpuMain is sometimes running too long (like what is seen in comment #42)!  [see attached "crgpumain-with-chromes-raf-implementation.jpg"].

And when I turn Aero back on, my rAF implementation starts to show 'some' fails, but far less than the number of fails seen with Chrome's rAF implementation.

My test setup:
 - Dell L702X / Windows 7
 - i7 2630QM 2.00Ghz (4 cores / 8 threads) 8GB
 - Intel HD Graphics 3000
 - browser: "Version 40.0.2202.3 canary"

Now, this 'workaround' to Chrome's jankiness is NOT at all practical (because replacing rAF with setInternal() that spin-waits, burns far too much CPU time; and you need to know the precise Hz of the display ahead of time), but I think this test result clearly shows that Chrome has some other internal timing/delay/synchronization problem, that is the root cause of this bug report.
57.4 KB View Download
66.0 KB View Download
Status: Started
When Aero is turned off the browser uses the system vsync again, so the smoothness you're seeing is the result of that being re-engaged.

I know that based on that the simple solution seems to be to turn vsync back on all the time, but unfortunately it's not that simple. All Chrome windows share a single GPU process, and if we begin waiting on SwapBuffers then your framerate begins to be divided by the number of Chrome windows onscreen: 2 windows will run at 30Hz each, 3 windows at 20hz, 4 windows at 15Hz, etc.

Obviously the current method isn't proving to be reliable enough for smooth animations, but it's going to take some work to find a method that is. Please be patient while we evaluate the possible courses of action here.
> When Aero is turned off the browser uses the system vsync again, so the smoothness you're seeing is the result of that being re-engaged.

Nope!  That may be how things were designed to work, but that is ABSOLUTELY NOT how things are working on my system (if you are right, then point #1 below would be impossible).  Please reread #43 again.  Chrome is never smooth, regardless of Aero on or off.  In summary...

1. With Aero off, Chrome's rAF is crazy jerky and shows tons of vsync failures -- in other words, it is NOT smooth.  The cause is that CrGpuMain sometimes runs too long.  What causes that is not known, but the ultimate cause of the problem.  A minor subpoint is that I see screen tearing cycle through the display, which is caused by a Hz mismatch.

2. With Aero off, and MY rAF implementation, there are *NO* vsync failures.  And I see screen tearing locked to a fixed point on the display because the Hz matches.

3. With Aero *ON*, MY rAF implementation blows away Chrome's rAF implementation -- almost no vsync failures, vs tons of failures for Chrome's rAF.  Again, the cause is CrGpuMain running too long.  What causes that is not known.

Something is causing CrGpuMain to run too long -- that goes away when rAF is NOT used.
Regarding comment #45, here are some videos (under those test conditions)...

a) shows point #1 in comment #45 -- vsync failures, with a screen tear cycling from bottom of the screen to the top.  This is easy to see in person at 60fps, but very hard to see in this video -- you can just barely see it when the video is played slowly (see also attached chrome-tear.jpg):

b) shows point #2 in comment #45 -- no vsync failures and the screen tear is fixed, and very easy to see, at about 25% of the way from the bottom (see also attached fixed-tear.jpg):

67.8 KB View Download
68.5 KB View Download
I just stumbled across another clue for the vsync jankiness in Chrome Canary that remains, with the #30 fix in place...

The jerky3.html test always had an 'Odd frame delay' option.  I just added an 'Even frame delay' option.  The delays work really well to expose Hz mismatch problems, but the options were designed that you use one option or the other (not both at the same time).

Well, here comes the bizarre part -- When both options are checked, meaning that the rAF callback will always just chew up CPU time (spin-wait) for 33% of the frame interval (5.57ms on my computer) for ALL frames, the jankiness in Chrome goes away (using Canary 40.0.2204.0).

Since this is all rather counter-intuitive (that adding cpu overhead makes Chrome jankiness go away), here is the video proof on my system:

For the first ten seconds of the video, there is jankiness (no added intentional delays).  Then just after 10 seconds, you can here me click on both the odd frame and even frame checkboxes (and the performance graph charts that 33% of the frame time is used up) -- and then Chrome's jankiness goes away.

This is very reproducible, and reversible.  Unchecking both odd/even frame delays causes Chrome jankiness to return.  Checking both options once again makes Chrome jankiness go away.

Comment 48 by, Oct 30 2014
I'm trying to understand how your test works and wanted to check I'm on the right path.

The test paints the cyan image on "even frames" and then a red image on "odd frames". If you're correctly displaying odd-even-odd-even frames then visual persistence will make the image look gray, but if you display two frames of the same type in a row, you'll see flash of color. Is that correct?

Thus this test not dependent on the time it is called (or the value at that time), just that RAF is called only **once** per vsync period and then the result is displayed in just **one** vsync period (not necessarily the same period).
@mit #48, yes (an inconsequential correction: the test displays cyan on "odd frames" and red on "even frames").

The word FAIL on the screen looking "gray" is purely a visual effect created when cyan is displayed for 1/60 second followed by red displayed for 1/60 second, repeated over and over -- so your eyes are the 'detector' in this test.  The test works best when you look directly at the word FAIL (you have probably noticed that if you look elsewhere on the screen, that your peripheral vision detects the flicker).  There are two primary ways you will 'see color':

The first way is that a frame is outright missed (rAF not called back when it should have been called back), so that the prior frame stays in place for multiple vsync periods.  That is why the performance graph is there.  It helps to verify that rAF is being called back 'on time', and confirms that the callback is itself executing in very little time.  Many tablets can't handle this test.

The second way (that I see in my Chrome testing), is that frames (rAF) are being produced on time, but that the back end is unable to place those frames into unique vsync periods.  So what ends up happening is that one vsync period receives NO frames and the next vsync period receives TWO frames (with only the second frame making it to the display).

Any time a frame stays up on the screen for two 1/60 time periods, your eyes will detect the color.
Just want to point out that Construct 2 users have noticed V-sync quality issues in Chrome and have been wondering about it. Here's a ~90 page thread on our forums about the issue:

I also filed bug 424563 which may be related, and also provides measurements that allow different browsers to be compared; as the bug notes IE11 appears to have better/less janky v-syncing.
I'm a Construct 2 user. There is a thread on the construct 2 forum that has become a discussion of this very issue (see page 12 onwards specifically).
Comment 52 by, Nov 4 2014
BTW This issue is unrelated to issues with the timestamp that RAF is given
(which I'm working on fixing).
Issue 425593 has been merged into this issue.
Issue 429950 has been merged into this issue.
Project Member Comment 55 by, Nov 6 2014
The following revision refers to this bug:

commit 3f72599ead7c0ee7922afedf93ffae17f5f45f88
Author: bajones <>
Date: Thu Nov 06 19:47:27 2014

Allow Windows to use system Vsync for a single window each swap

This makes the common case (one browser window) smoother, but doesn't
help multi-window smoothness much.


Review URL:

Cr-Commit-Position: refs/heads/master@{#303074}


bajones, the latest update (comment #55) has made vsync under Canary rock solid on my test system.

But now, system vsync appears to always be used, even when the "disable-gpu-vsync" command line option is used.  Is that flag supposed to still work?

Also with this change, in chrome://tracing, CrGpuMain now appears to always use up the entire frame time -- which I presume is related to waiting for the swap?

FYI: A revised and updated jerky3.html test has landed at
Project Member Comment 58 by, Nov 12 2014
The following revision refers to this bug:

commit 0d49051cb119a5fad0f8291834fd93d0225f39be
Author: bajones <>
Date: Wed Nov 12 00:32:07 2014

Revert of Allow Windows to use system Vsync for a single window each swap (patchset #2 id:20001 of

Reason for revert:
Possibly introduced regressions into smoothness.tough_scrolling_cases

Original issue's description:
> Allow Windows to use system Vsync for a single window each swap
> This makes the common case (one browser window) smoother, but doesn't
> help multi-window smoothness much.
> BUG=422000
> Committed:
> Cr-Commit-Position: refs/heads/master@{#303074},,

Review URL:

Cr-Commit-Position: refs/heads/master@{#303759}


Comment 59 by, Nov 12 2014
jerryj, could you attach your updated vsync test? The previous versions have been really useful.

mit..., the updated vsync test ( is attached (see index.html).  Most parameters can now be tweaked via the GUI (no need to edit/change JavaScript).

The new test allows for a custom Hz to be used, along with a ms skew -- which allows (when the Hz matches the monitor Hz) the tear location to be precisely placed on the screen (at least with Windows 7 and Aero off).  This new test has revealed some unknown internal jitter inside of Chrome.

Namely, in Chrome 38, I am seeing that the JavaScript animation callback is being called back exactly on time, that the callback returns is approx 1ms, but on a periodic basis (like some background processing jumps ahead of a screen update), the 'tear location' on the screen is pushed down the screen a little.  By my calculations, the distance equates to a 4-6ms delay/jitter in updating the screen.  In Chrome 40, swap buffers appears always on, so I can not run this new test (can not see any tear location) to see if the jitter is gone.

Only FF is able to deal with the new test, and is able to place the screen tear at the same location on the screen over and over (only with custom hz, as vsync in FF appears busted) -- meaning that the pipeline all the way from the animation callback until everything is placed onto the screen, is VERY consistent from one frame to the next.

If there is anything inside the web browser internals that is delaying things -- this new test can easily spot it (well, your eyes can spot the problem).
2.3 MB Download
With the fix reverted (comment #58), Canary is (understandably) now janky again.

Another clue ... regarding Canary, vsync, and the inability to turn off the swap buffers.  When I was running a tearing demo full screen (F11) under Canary 41.0.2219.0 (with Aero off), Canary is apparently unable to complete swapping buffers during vsync -- because I can very clearly see a tearing location a couple of pixels from the top of the screen (see attached photo) in every frame.  Very consistent.  This seems to suggest a timing problem in Chrome's swap buffers.  And every once in a while, the tear location jumps down another (approx) 150 pixels for a split second (suggests to me that swap buffers is not running with a high enough priority).
27.8 KB View Download
bajones, I just stumbled across a HUGE CLUE as to the true cause and source of this bug (in Canary after the first fix)...

When I open Canary (41.0.2224.3) and go to, I see a lot of VSYNC synchronization failures (FAIL flickers red; a lot).

But when the Canary browser window is RESIZED, *all* jankiness goes away, from that point forward.  I have repeated this now over a dozen times, and each time, a window resize fixes the problem (moving does not fix the problem; only resizing).

Can you reproduce this 'fix'?
Comment 63 Deleted
Same thing here. It doesn't matter whether Canary is brought up windowed or full screen; any resize action whatsoever seems to correct vsync failure.  Moving the window does not; only resizing it. 

Afterwards, vsync stays corrected whether the active window is windowed or maximized. 

When canary is set to start maximized, vsync seems to be set correctly 99% of the time (It failed once for me, but I couldn't get it to happen again). 

Conversely, vsync almost never works when starting windowed...until the window is maximized/resized.

Version 41.0.2225.0 canary (64-bit)
Interesting results and I can duplicate it as well.  However the variation in dt measured by my other test (linked below) doesn't seem to change if the window is re-sized....

In Chrome Version 39.0.2171.65 m I see no difference in dt variations after the window is re-sized.  I also see a vast improvement in dt control in v39 compared to v38, but there is still quite a spread of dt values for such a low demand test.

In case you haven't seen the test from my bug report (linked to this one), here is a link.  It scrolls a simple background image and creates and destroys one small sprite per tick; press start and it will gather dt values for default 30 secs and then display the results in graph form.
Just to add from my previous comment, running in Chrome Canary Version 41.0.2225.0 canary (64-bit), the dt spread is far worse than the spread in Chrome Version 39.0.2171.65 m...!
I have updated my test (link = ) so higher dt values are recorded; I noticed the following spread of delta times for chrome 39.0.2171.71 m and chrome canary 41.0.2230.0 canary (64-bit).  In the attached image from Canary you can see that there is a spike of delta times at 20 ms - which is not compatible with a 60 Hz refresh rate (or, at least, I would expect to see a corresponding spike well under 16.7 ms to compensate).  Thus frames are being dropped as a norm for both versions.
chrome canary 41.png
10.1 KB View Download
While resizing Canary's window fixes the VSYNC issue, the 'resize' interestingly causes 'on battery' problems.  See issue #439751.
Comment 69 by Deleted ...@, Dec 20 2014
I have the same problem in all version of chrome after Version 36.0.1985.143 .
On windows 8.1
but i dont have this problem on Maxthon or IE11.
is there any fix about this problem ?
I would like to add my 5 cents to this:
Seems that when bringing up the built in Task Manger in latest Canary v41.0.2255.0, the test drops visible frame in a consistent way and you can clearly see the red/cyan colored FAIL.
bajones, can you provide a status update on this issue?
Project Member Comment 72 by, Jan 2 2015
The following revision refers to this bug:

commit 9b71e13d22829c2df1620211049a6032628ebea8
Author: bajones <>
Date: Fri Jan 02 23:37:41 2015

Allow Windows to use system Vsync if only one window is swapping

This makes the common case (single browser window) smoother. Having
multiple swapping windows visible will force the previous behavior.

This patch differs from a previous variant (
in that there's now a "timeout" before we attempt turning on vsync again.
Specifically, we need to go for 60 frames without a frame where two
surfaces swap in order to turn Vsync on. This accounts for cases where
low-frequency updates in one window (blinking cursor) don't trigger
frequent vsync state changes. Also prevents pathologically bad cases
where two frequently updating windows would cause one another to skip
alternating frames.


Review URL:

Cr-Commit-Position: refs/heads/master@{#309861}


bajones, the fix in #72 ( suffers from the same bug reported in #62 -- that VSYNC in Chrome is BUSTED until the Chrome application window is resized.

With the latest patch Canary is very smooth for me. Using this test:

Jank is around ~2ms and max jank is <4ms which is excellent - doesn't appear to drop a single frame.
ashlaa/74, the test you pointed to will not detect the vsync issue discussed here.  The core problem is that frames ARE being produced on time with no jank whatsoever -- so even tests that report absolutely no jank, and are rendering ALL frames -- can still have vsync / missing frame issues.  The entire problem is that Chrome internally is not placing rendered into unique VSYNC intervals.

I have yet to see an improvement with this.  Attached is an image from my test on the latest canary.  There's a marked vsync spike at approx 20 ms - which guarantees missed frames at 60 fps.
20150122_Version 42.0.2283.5 canary 64-bit.png
6.7 KB View Download
...unless the huge spike at 16ms is an attempt to compensate for the higher figure.  I cannot tell from this test, but there are a lot of other vsync time hits at lots of different values up to 25 ms as well.
Labels: -Cr-Internals-GPU-Scheduling Hotlist-Scheduling Cr-Internals-Compositing
Canary 42.0.2287.0 is now completely unstable.  requestAnimationFrame() callbacks are now all over the place.

Something changed (for the worse).
What changed in Canary to totally bust rAF and vsync synchronization????  See #79.

See attached chrome-40.0.2214.93.jpg to see a 'good' test using Chrome and

See attached canary-42.0.2292.0.jpg to see a very bad test using Canary and -- that shows that the latest Canary is very busted.
165 KB View Download
197 KB View Download is still pretty bad in 42.0.2292.0 canary. It regularly janks >16ms and sometimes janks >32ms.

We are hearing from Construct 2 users that they are delaying Steam releases of HTML5 games (via NW.js) due to this issue. Native games are pretty good at v-sync but right now HTML5 games are pretty janky in Chrome and don't compare too favourably to native. IE11 has very good v-sync quality from our measurements and sets a good benchmark to compare Chrome against. I wish to emphasise that this issue is delaying commercial game releases. It would be reassuring to see more involvement from Chromium engineers on this, or at least have some kind of status update on it.
Almost half a year, and still no improvement over IE ?
why dont you fix this?
Well, the number of votes almost tripled over the past few days. I think it's a sign.
Mozilla's Project Silk sounds like the right kind of solution to this problem: They describe how hardware vsync timers are more reliable and provide better performance than software timers. Maybe this is what Chromium needs as well?
Comment 87 Deleted
Comment 88 Deleted
Comment 89 by, Feb 2 2015
Recently John Davis also had problems with jerking and performance in Chrome (but not in IE) on windows.

I've also observed that the smoothness of animation can differ a lot between browsers and platforms.

I suggest that tests are run on the nightly builds to detect latency, jerkyness, vsync busts and other timing related failures/regressions and bells are going off when that crosses defined levels of variance.

It's of paramount important for browsers to make realtime graphics as smooth and low-latency as possible. Otherwise it's very difficult (and rightfully so) to convince native developers that browsers are worth their time.

As an aside to those wanting the situation improved, you can use this standalone build bisect script ( to report a more definite and accurate build regression revision. While inconvenient, it would help immensely, particularly for Chromium devs unable to repro locally.
Is Chromium's rendering driven by a hardware v-sync timer or a software timer?
@ashlaaays: Unfortunately there's not a straightforward answer to that. With newer builds on Windows we try to use hardware vsync when possible (primarily single window case), but will fall back to using a software timer if the case is more complex than a single hardware surface refreshing. Even with hardware vsync in place we're still allowing the software scheduler to run to try and better manage GPU time, but it's possible that's been causing conflicts recently.

I'm going to try and post something here soon that allows you to test several different modes of frame limiting so that everyone that's been having trouble in this thread can provide some more targeted feedback. Unfortunately we're not seeing the same results internally, so we're going to need some community feedback to narrow down what combination of hardware and software settings are problematic.
@bajones: do you think Mozilla's architecture of having a hardware v-sync timer driving both paint and composite is the best way to go?
I haven't read up on Mozilla's approach yet, so I can't really comment on it. Has your experience with Firefox builds using that technique been positive?
@bajones: I don't think Silk is testable on Nightly/Windows yet, but it's nearly there, I will test it and add feedback here when it's available. I had assumed that was what IE11 was doing since it is pretty solid and the delta-time measurements are accurate too, but it's hard to confirm since they have a pretty closed off development process.
Okay, for anyone responding to this issue with smoothness/vsync issues here's a simple way you can help us better understand the problem:

 1) Download this experimental Chromium build (Windows only) and extract it to a temporary folder:
 2) Run it with the command line flag --hardware-vsync-only. (Must be passed in via the command line, it doesn't appear in about:flags)
 3) Test content that you've had trouble with in recent Chrome builds. Is it smoother, more jittery, or about the same?
 4) Close the browser then re-run with the command line flag --software-vsync-only.
 5) Test the same content again. Is it smoother, more jittery, or about the same?
 6) Visit about:gpu and save that page's contents to an HTML file.
 7) Report your findings on this bug, making sure you attach your systems about:gpu page.

I appreciate your help and patience while we narrow down this issue!
bajones/#97 - normal .ZIP file please...
Zip file of the build from #97, for those that prefer it:
Thanks for giving this issue some attention. It's something I've noticed for a while now.

I tried running the Chromium test build using this page as it seems quite good at highlighting the problem for me:

My system:

Windows 7 64bit tower PC Intel i7 X980 @ 3.33GHz
SyncMaster S22B300 (cheap 1920x1080 LCD)
GeForce GTX 960 (latest drivers)


--hardware-vsync-only - frequent fails
--software-vsync-only - smooth

Note that on this system, both Chrome current and Canary run the vsync tester smoothly.

On my home PC, current Chrome fails frequently, while Canary runs smoothly. I'll try running the test there later tonight.

Attached my about:gpu results.
83.8 KB View Download
Results for me: Running the Chrome in #99, with both --hardware-vsync-only and --software-vsync-only, both FAIL as per the canary-42.0.2292.0.jpg image attached to #80.

See attached for my about:gpu results.

I think that there was some change made in a very recent Canary (hopefully within a couple of days of the canary version referenced in the #79 comment) that introduced a totally NEW GPU issue/bug into the mix -- that I can easily see in the vsync test.

--> Because when I disable the GPU for canvas ("Disable accelerated 2D canvas") in about://flags, the #79 problem goes away -- and works (I see a few vsync failures, but that is to be expected with the extra overhead of a software rendering and is consistent with 'gpu off' testing months ago).
87.0 KB View Download
Observed results:

Hardware V-sync (--hardware-vsync-only):

Running shows me ~40fps with major frametime deviations. This persists when chrome is windowed, maximized, or in fullscreen mode.

Running gives 60fps most of the time, though subjective quality is still not ideal, and the in game jank measurement regularly exceeds 10ms, sometimes going as high as 22ms.

Software V-sync (--software-vsync-only):

Running gave me varied results. On it's initial run in windowed mode, it was hitting 60fps. However, maximizing the window caused an unusual behavior I can only call 'yo-yo-ing', where the FPS slides smoothly up and down between ~45fps and ~30fps. This persisted when maximized, fullscreen, and even when reverting to windowed mode.

Running again gave 60fps most of the time, though subjective quality was uneven, with smooth performance at times, and terrible stuttering at others, even when the in-game jank measurement failed to indicate such deviance.

No flags:

When running the experimental build without flags, also exhibits the 'yo-yo-ing' behavior described above, which seems absent when using the hardware timer.

Chrome Stable Version 40.0.2214.93 m: 

The current stable, while dropping a frame or two on a regular basis, is quite good overall even on the unforgiving '' test, coming close to IE 11. IE 11 still gives a cleaner graph, though.

Chrome Canary Version 42.0.2292.0 (64-bit):

Also has the 'yo-yo-ing' behavior which tries to adjust fps according to some odd internal logic, and in doing so butchers motion quality. Doesn't always kick in, but when it does, frametimes can't ever seem to recover.

About:gpu is attached.
9.2 KB View Download
First off, thanks for looking into this!

Ran tests with both flags at :

--hardware-vsync-only - frequent fails (full screen or windowed)

--software-vsync-only - smoother - (better at full screen then windowed) Unstable on immediate start after about 1 sec - much more stable. Note: I observed about every 20 seconds or so a hiccup on the graph and a noticeable jank/jitter in animation but vsync fail box stayed gray.

Win 7 Pro 64
Xeon E3-1230 @ 3.30GHz
32GB Ram
Nvidia GTX 650Ti 2GB

about:gpu attached

4.3 KB View Download

sbperftest: no visible jank, even though test measures some dropped frames and jank flawless scrolling, although the measurements indicate a spike every 1 second on a red line.


sbperftest: visible jank, although test measurements approximately equal to --hardware-vsync-only very obvious jank, including obvious jank which appears to run regularly every 1 second. Interestingly the measurements indicate that everything is fine, and there is a green line always close to 16ms.

Verdict: --hardware-vsync-only is visually flawless with perfectly smooth scrolling, although JS measurements indicate it is poor. --software-vsync-only is visually janky, but JS measurements indicate it is OK. It appears JS code is not capable of measuring anything which correlates with the actual on-screen display. Hardware v-sync is very obviously better on this system. GPU page attached.
83.6 KB View Download
@bajones: I wonder if changing ShouldTriggerBeginImplFrameDeadlineImmediately to always return true on Windows will help start (and thus end) our frames more consistently relative to vsync.

It'll trade off a bit of latency and throughput in some cases, but should help smoothness.
As specifically Chrome 38 is mentioned as the start point and everyone is now talking about timers, is this system clock tick change that looks like it went into 38 related?
@#97 bajones

Hardware vsync - reported display varies wildly from 30Hz to 55 or so, never reaching 60Hz. Visually smooth at times, then goes into jerky movement and back to smooth again.

Software sync - 60Hz and 60fps, but perceptively the movement doesn't quite feel smooth. Much more predictable, but with occasional jump.
139 KB View Download
Tested on another system (a high end desktop):


sbperftest: minor jank but generally smooth flawless smooth scrolling but measurements still showing spikes


sbperftest: generally smooth, about the same as with hardware vsync flawless smooth scrolling about the same as with hardware vsync but measurements don't have spikes

Verdict: on this more powerful system, the two seem to work out about the same. gpu stats attached.
136 KB View Download
My observations...

(1) The VSYNC bug orignally reported by this 422000 bug report was 'kind of'/mostly fixed -- where VSYNC was in fact busted UNTIL the Chrome application window was manually resized -- which for some crazy reason, a manual reisze all of a sudden caused VSYNC to work GREAT in Canary.  See comment #62.  Also, VSYNC in the latest release (40.0.2214.94 m) works great against  See comment #80.

(2) There was an unknown change in a very recent Canary (>2276 and <=2286) that totally busts VSYNC once again (for me).  See the attached canary-42.0.2292.0.jpg in comment #80 showing that VSYNC is completely unstable for me.  While comment #79 says "42.0.2287.0", I am fairly certain I first saw the problem in the prior 42.0.2286.0.  And the last time I ran Canary against was 42.0.2276.0 (which I assume worked fine).  That gives a range from 42.0.2276.0 to 42.0.2286.0 for the introduction of the latest VSYNC problem.

(3) The latest vsync issue goes away if the GPU if turned off for canvas.  See comment #101.

(4) The latest vsync issue goes away if I view the web site at a very small zoom factor (like around 25%).

(5) When the test was configured to use setTimeout() instead of rAF, once I clearly saw the graph look great, but the crazy thing was that the display was only updating once every half second or so.  Hopefully that is a huge clue to those working on Chrome internals (I was able to replicate this issue, but only a couple days ago, and not since).

(6) on a second, more modern and powerful system, I don't see the latest vsync issue.

Hope this helps...
bisect results:

  312868 - VSYNC works fine (after resize app window fix)
  312958 - VSYNC totally busted, as per comment #80 canary-42.0.2292.0.jpg attachment

@jerry (and anyone else)

Are you seeing the FPS 'yo-yo-ing', as described in post #102, when running on Canary or the experimental build w/ --software-vsync-only? This struck me as the most bizarre and worrying quirk I'm seeing in these newer builds, but I'm wondering if it's exclusive to my machine. 

I do have an iGPU (HD4000, latest drivers) vs a dedicated GPU, but it shouldn't be having any trouble with the vsynctester page. 

Can you reproduce?
@TiAmIsT/111: No, I don't see the 'yo-yo-ing' on my system.  What happens when you change your page zoom to something else (as per point 4 of #109)?

No, I still seeing the described behavior, both in the experimental build, and in Canary, but not in stable. 

At first the test runs fine; then, after a time (maybe 15 to 20 varies) the framerate begins to dip, stuttering becomes atrocious, and the FPS proceeds to oscillate from around 48fps all the way down to ~30fps. No matter how long the test is left this way, or what viewing mode the browser is in or is changed to (fullscreen, maximized, windowed) the test never recovers until the browser is closed and re-opened. Even closing the tab and re-opening it doesn't work. Chrome stable does not appear to have this issue.

On a separate note, there are two actions that can reliably cause motion stuttering in all tested versions of chrome, including stable:

1. Mousing over chrome interface elements, like bookmarks, back/forward buttons, etc. 

2. Even worse, position your cursor over the top of the chrome window (in Aero, the area you can see through), click and hold with left mouse button. Watch the motion quality get destroyed, and FPS dip below 30. Even worse is if you drag the window around.

#2 can also be replicated in Firefox. IE 11 is the only browser that retains smooth motion under such duress.
Comment 114 Deleted
@TiAmIsT/113 (1&2) I am experiencing this as well - "The actions that cause motion stuttering in all tested versions of chrome, including stable:" 
Here is a video of what I see running against "Version 42.0.2294.0 canary" (the new VSYNC bug introduced between r312868 and r312958):

@TiAmIsT: I added "Suspend canvas updates" to where all internal timing continues, but display/canvas updates do NOT happen.  This 'should' cause 'yo-yo-ing' to stop, but then does the 'yo-yo-ing' restart after the option is unchecked?  Also, does turning off GPU for canvas fix the issue?
To any and all Google employees who are listening:  The change of this issue to "Comments by non-members will not trigger notification emails to users who starred this issue" is draconian.  So when TiAmIsT/113 asked me a question, the only way that I know that question was asked (since I now longer get automatic emails when this issue updates) is if I manually POLL this issue and look for new comments!?  What an incredible waste of time.  Where did 'common sense' go?  Rather, send email updates to *anyone* participating (anyone who has commented) in this issue.

From now on, if I don't respond to a question here, the fault lies with Google for not informing me that the question was even asked (that this issue was updated).  Just ping me directly at, where ###### is the number of this issue.


Well, I'll send this to your email in addition, but I'll also post here for the benefit of anyone else following this.

In Canary, using 'suspend canvas updates' stops animation (as expected). When resuming, a clean 60hz graph is shown, and sync is initially correct again. However, FPS begins to fall anywhere from ~1 to 10 seconds later.

It's come to my attention that this bug is categorized as 'OS-Windows'.

Rendering/performance regression for chromium and chromium derivatives has been observed on platforms other than Windows, including Linux and OSX, as well as android, all stemming from the release of v38.

For android specifically, you may find it productive to contact the Intel Crosswalk team. They provide a cordova compatible build service that packages a recent chromium/blink runtime with apps for enhanced performance on Android 4.X. They have been experiencing performance and stability regressions with newer versions of the runtime, starting with chromium v38, and have publicly stated that they suspect these issues originate from the chromium core itself.

Unfortunately, many of the app developers encountering this issue (myself included) are not well versed in the workings of chromium, making it more difficult for us to pinpoint what is causing this issue.

It doesn't help that the chromium project does not provide binaries for older versions, making it needlessly difficult to test older versions vs newer.
Labels: -OS-Windows OS-All
Thanks for bringing up the point of this not being a Windows-only issue.

As for older Chromium binaries, it's not the easiest thing in the world to navigate but you can get then here: 
@TiAmIsT, thanks for that update.

OK, time for a change of pace and some good news.  I thought I should document this 'success' while Chrome (release) still works great for me.  Using "Version 40.0.2214.111 m", and after the resize Chrome's app window trick, and on a Dell L702X notebook from 2011 (Intel HD Graphics 3000), Chrome actually passes a "double the frame rate" VSYNC stress test with flying colors (the test procedure is documented in the "How to test a web browser" section on  Here is a video of that:

Only Chrome passes this 'double rate' test for me.  The fact that it can do so with inter-frame times around 8.3ms, even on notebook hardware from 2011, is nice to see.  FF and IE both fail the test (and both fail even on my newer hardware).

@bajones, if you are having trouble reproducing or bisecting the latest VSYNC issue, hopefully the ranage r312868 to r312958 is a small enough range, that if someone there builds a rev, I can test that rev to help further bisect the range...

@bajones: bisect of new VSYNC problem is now between r312916 (works) and r312924 (fails).  This is as far as I can go -- ball in your court.

Comment 124 Deleted
Comment 125 Deleted
Taking a cursory look at the commits between the two versions @jerry is mentioning, two commits leap out at me: The very next commit, r312917, which appears to be an update of blink, and also the update to skia in r312918.

I have yet to DL and confirm @jerry's bisect of r312916/r312924, but when I do I'll post back. 

Also going to give the android versions a go -- there's a build of r312916 and r312919, so that's about perfect for my working theory -- and see if I can get a couple other people to test the mentioned builds.
Observed results:

r312916 did not always give a good result, with results slightly worse than the current chrome stable. Also, I still see the 'yo-yo-ing' issue mentioned before.

r312924 did give a worse result than 312916, though not drastically so. Otherwise, similar characteristics to my previous tests.

sbperftest --

Both tested versions had good performance, good subjective motion quality, and reported minimal jank. This test simply doesn't seem as finicky as the above.

I have declined to test the android builds for now as I had hoped to test v38 vs v37, but I haven't figured out which build is which yet...there are quite a few ;)
Comment 128 by, Feb 6 2015
The effect can also be observed in the dev-tools timeline. For instance on my machine (linux) on chrome stable timings are like:

20.086ms, 13.828ms, 16.530ms, 16.348ms, 16.981ms, 18.898ms, 14.497ms, 16.792ms, etc.

The effect of this jitter is clearly visible (to me) as reflected on screen by simple animated items.

Drilling down into the call chains does not reveal any culprit. Comparing to profiles, the CPU is 98.87% idle.

As an aside, simply running requestAnimationFrame on a plain update function @ 60fps incurs a JS Heap grow of 200kb/second (3.3kb/frame).
@bajones: It is clear from looking at the F12 timeline while running in r312916 (works) vs r312924 (fails) that there was some major regression in the graphics subsystem.  See attached captures.

107 KB View Download
115 KB View Download
@bajones, I was playing around with r312916 and --disable-gpu-vsync (to run at max fps) and run into a strange interaction with the need to resize the chrome application window to get vsync to work (see comment #73).

--disable-gpu-vsync will only work as long as the Chrome application window is NOT resized.  The moment you resize the application window, the fps drops back down to the bounded rate (effectively disabling the --disable-gpu-vsync option).
Re comment 128, I suggested a while ago in issue 437212 that v-sync events be shown in the devtools timeline. With a jumble of differently timed frames it's hard to see how they line up with v-sync events. If they were shown it could help developers learn more about v-sync issues, and possibly also help the Chromium developers in dealing with this issue. Right now v-sync is just invisible magic happening somewhere inside the browser.
Regarding the GPU performance regression that was reported as a VSYNC problem in comment #79 (see also comment #123) -- it appears that the latest Canary 42.0.2298.0 has resolved the issue for me.  The 'fix' happened between r315096 and r315107.

Does anyone else see an improvement?

Comment 133 Deleted
These comments are in reference to Chrome(Canary) Version 42.0.2298.0 canary (64-bit).

Bench has improved since the last few canary releases, but the current stable is still superior graph-wise, and has more consistent subjective performance. In ideal conditions it's impossible to tell the two apart judging by the scrolling quality.

I can observe a couple actions that can still induce jitter, including:

1. Mousing over tabs, or rapidly in and out of the window. Try moving your cursor in an arbitrary circular motion, watch what happens to the graph and the scrolling image.

2. Resizing the window. In particular, grabbing onto a side of the window and holding it causes the framerate to plummet, even if the cursor is held still.

3. At times, the scrolling quality suffers quite badly without being reflected in the graph. This happened to me multiple times, always seeming to occur when chrome was windowed. After a few seconds this would always correct itself. Visually, it looked like every other frame was being missed.
42.0.2299.0 canary is looking good here. Both JS measurements and visual appearance are good.
To document what is happening in Chrome release: From 40.0.2214.111 to 40.0.2214.115 (today), Chrome just switched from using the correct 59.803Hz (on my computer) to the incorrect idealized 60Hz.

Yes, that's a known issue and was an intentional revert on our part. The fix that was originally implemented was to start using higher resolution timestamps to track vsync intervals and offset, but this had an unforseen dependency on low-res timestamps elsewhere in the system. On some hardware the mismatch between the two could be pretty severe, causing issue like We reverted the high res stamps in 40 and 41, but have taken the steps needed to correct the low/high res mismatch in 42, which should see much more stable performance at this point.
To document what just happened in Canary from yesterday (43.0.2314.0) to today (43.0.2315.0), after applying the 'fix' discussed far above about having the resize the Canary application window to get VSYNC to work (Win7), requestAnimationFrame render (green/red line) timings at are now 'busted' compared to before.

Previously in Canary, after resizing the app, the render line remained the same (excellent).  But after the update to 43.0.2315.0, after app resize, the render line is now very janky.  See attached.
50.5 KB View Download
37.1 KB View Download
Comment 139 Deleted
Can't really reproduce as of 43.0.2316.0. Resize does occasionally cause bad stuttering for a few seconds afterwards, but then clears up. Tried various window sizes, maximized, and fullscreen.
Here is a video showing the VSYNC problem stated in #138 (also a correction to that post, change 'render' to 'inter-frame')

The first half of the video is Canary 43.0.2321.0 pre app resized.  The second half of the video is what happens after the Canary application window is resized (see mouse cursor on right border).
Comment 142 Deleted
[FYI: deleted last comment, moved to new issue 464740] now includes an option to graph the "frame offset from vsync", which can be very informative (and just helped find a high latency mode issue in Chrome).
bajones, every once in a while Canary fails to vsync properly -- and apparently falls back to an interval of 16.666ms, which in Hz is 1000/16.666 or 60.002400, which is exactly the Hz I see (attached), when using Canary 43.0.2332.4 refs/branch-heads/2332@{#6}

Is this a known issue?
128 KB View Download
In newer windows builds we use system vsync if only a single browser window is drawing. If multiple windows begin rendering at the same time (and in this context things like tooltips may count as a window) then we switch back to an older behavior where we attempt to manage vsync ourselves temporarily. It should revert back to system vsync after about a second of a single window drawing again.

This is a stop-gap solution intended to address a common use case until a more robust and permanent solution can be implemented. It may be what accounts for your occasional vsync hiccups.
@bajones, thanks
So we should avoid tooltips (title attributes) when unnecessary? (they don't work well with touch anyway)

Its this visible windows or do hidden tabbed windows count?
Only visible windows. Hidden tabs don't redraw, and as such won't trigger the fallback.
Very significant new find.  How to achieve perfect VSYNC synchronization in Chrome.  A prototype confirms it can be done.  See issue 467617.
I've recently discovered anomalous Chrome performance issues that may relate to this issue.

History: is an Agent Based Modeling system porting NetLogo ( to JavaScript.  At the first usable commit, I did a 3 week performance investigation on Chrome via the profiler, resulting in a doubling in speed and Chrome outperforming the other browsers by a wide margin.  The tests are done with sample models, our "unit tests".

Recently I revisited the performance and was amazed to see that the initial tests fell to unexpected lows, with all other browsers outperforming Chrome considerably.  The only difference in the testing was that I used the recent Chrome (I haven't found a way to get a year old Chrome, alas).

The 64 tests I performed are attached, details provided if needed. The four repos are in
To run, for example, the earliest "ants" model, use:
(Note the web repos use YY/MM/DD so as to sort oldest to newest)

All tests were run incognito/private to insure no extensions etc were at fault. The platform is a Mac Mini dual display with latest Yosemite and most recent browsers.  I see similar timings with a MacBook Air, single display. Our animator uses rAF for all drawing with an option to use a setTimout for model computations.

This is a huge problem for us as we use this for the next generation of our First Responders simulation system (

Is it possible our problem relates to this issue?  Can you help me get an earlier version of Chrome to regression test with?

Thanks .. and let me know if I can help in any way.

   -- Owen

              Chrome  Canary  FFox    Safari
  ants:          8     25      30      58
  diffusion:   78/30  77/31   59/31   75/31
  fire:         46     48      46      56
  flock:       broke    5      14      26
  ants:         10     25      31      57
  diffusion:   79/30  79/30   59/30   68/30
  fire:         21     24      33      53
  flock:       broke  12/4    9/12    21/26
  ants:         10     26      30      58
  diffusion:   78/30  80/30   58/30   70/30
  fire:         23     26      38      50
  flock:       broke  14/4    8/11    20/25
  ants:         31     35      26      30
  diffusion:   47/30  49/30   39/30   32/30
  fire:         14     23      33      41
  flock:       broke    5      10      23
* 02/22/15: the current models (gh-pages)
** Current: current working dir w/ color integration
nn/nn: Multistep animation - steps/draws
broke: did not start! Sometimes ran if console opened

@ODensmore can you file a separate bug instead?

Try using to find out when things got slow in Chrome and report back in that other bug. We'll dup the bug into this one if it turns out they're the same issue. Thanks!
Thanks! Got an older Chrome, ran regression tests, proving it is a regression bug:

Hope it helps! Try to run with flag —disable-d3d11. Has it helped?
lo.../154, no, —disable-d3d11 does not help.
One more test, try --use-gl=desktop
lo/156, "--use-gl=desktop" makes things worse for me, and the Hz for my display is wrong (an idealized 60Hz, instead of the precise Hz).
As of today, the status of VSYNC in Chrome is:

Release (41.0.2272.101)- VSYNC busted (wrong Hz), but known, as per comment #137 above

Canary (43.0.2342.2) - In Win7, VSYNC is busted until Chrome window is resized (discussed above numerous times, and issue 465356);  Then, on almost any user interaction with the Chrome window, Canary flips into "high latency" mode (see issue 465105), which makes it seem like VSYNC is working much better than it is.
Can someone confirm this issue:

that, I believe, is related to some of the issues that brought up here?


For the record...

NEW ISSUE 1: Canary 44.0.2367.0 has completely broken  The VSYNC indicator flickers red/cyan constantly.  There is no more flickering gray (indicating the web browser is synchronized to VSYNC).  The cause appears related to drawing a (large) image to the canvas.  As this is a HUGE black/white regression, and this is Canary (and not the release), I assume someone made an inadvertent change, that your automated tests will catch this, and that the issue will be fixed in the next couple of days...

NEW ISSUE 2:  Within the last week, I have noticed that Canary is outright missing frames at the JavaScript level.  Inter-frame times are 16.6, 16.6, 16.6, 33.3, 16.6, 16.6, 16.6.  This is very unusual, as for the last year, production of frames at the JavaScript level in Chrome has been spot on (within 1ms) and the entire problem has been properly syncing those frames to the display.  Given the change in 43.0.2353.0 from 1ms inter-frame accuracy to almost spot on accuracy, there clearly was a subtle timing problem introduced, that is ultimately causing frames to be dropped.  Are you properly accounting for the inherent micro-jitter in the interval reported by DwmGetCompositionTimingInfo (qpcRefreshPeriod)?  You really need to pass the 'timebase' and 'interval' through a filter before use.  Just review the JavaScript source code at for an example of a filter that works very well.
See attached, supporting second issue reported in comment #160
42.8 KB View Download
@jerryj: Can you attach a trace from about:tracing when you see this 16, 16, 33 issue?
esprehn/162: see attached, begin frame id 1770 to 1771
4.4 MB Download
Re #161-163: SkipNextBeginMainFrameToReduceLatency is getting called for frame 1770 because the latency is increasing too much, but the main thread is fast and we can operate in a low latency mode.

The change in behavior is likely due to, whose effects we are tracking in issue 311213. However, I think it'll go away soon when we land the DisplayScheduler (, which should reduce latency later in the pipeline so we don't have to reduce it earlier in the pipeline.

briander/164: can I assume that what you describe in comment 164 is also causing CrGpuMain to appear 'maxed out' in the traces, when I know it can not be?  Also, just for reference, attached is a capture of the first issue, where the system is having trouble maintaining 60fps (on a system known to run with vsync disabled at 180fps).

102 KB View Download
Would someone from the Chromium team be so kind as to give a brief overview of what the status of this issue is and what kind of work is being done on it? From what I can see it is not a simple fix and requires architectural changes, since the issue has been open for about 6 months now and does not yet appear to be resolved.

This issue is of great concern to users of our HTML5 game engine (, as it can make HTML5 games compare unfavourably with native games. For months the perception has been building that Chrome can't play HTML5 games smoothly and that this is a major disadvantage of HTML5 compared to native. This seems to be doing a lot to detract from Google's claims that a jank-free, native-quality experience on the web can be achieved. It definitely can be achieved, as demonstrated by browsers like IE11 which appear to have flawless v-sync scheduling. It's also very frustrating as developers to pour effort in to making an effectively jank-free engine, and then it still looks like it janks because Chrome inexplicably drops three consecutive frames; meanwhile your developer evangelists are out talking a lot about how important it is to reach 60 FPS.

Anything that Google can do to alleviate increasingly serious worries that developers have about Chrome's ability to render smoothly at v-sync rate would be considerably appreciated. Ideally someone could give us a rough idea of the architectural changes being made, and an ETA when this issue is expected to finally be resolved.
Also if anyone from Google wants to get in touch to co-operate more closely on this please feel free to reach out to me at
I was investigating vsync issues on Windows recently and I found that certain applications can cause frame skips in chrome. One such application is flu.x which is used to control the color temperature of the monitor based on time of day. You might see frame drops at regular intervals if you're using such applications. Here's a detailed analysis of the problem:

I was able to confirm this problem using flux where a frame would be skipped every 10 seconds or so on chrome using a single window.
The latest Canary (44.0.2392.0) has done something.  VSYNC is now busted again.
80.3 KB View Download
Assigning to self since Brandon already did his part on this bug.

+simonhong since the "unified BeginFrame for Aura" patch ( definitely added noise to the graph.

Depending on how bad the jitter is, maybe we should have the unified BeginFrame work land behind a flag while we work on making it more responsive and integrating it with the rest of the system.

After the patch above, the rAF start can be blocked by work on the Browser's UI thread which is where the jitter is coming from. This isn't necessarily bad though since going through the Browser's UI thread also allows us to avoid races with user input, which can actually improve perceived smoothness; but we haven't yet integrated with jdduke's work to get that benefit.

Unified BeginFrame should also become more responsive as we move work off the Browser's UI thread with efforts like impl-side-painting in the Browser. We should probably see if there's anything else monopolizing the UI thread and what we can do about it (blink scheduler on the UI thread?).
Can we get a trace of the case where vsync is broken (from Canary)? 

If vsync isn't consistent under low stress and/or relatively idle cases, landing behind a flags seems reasonable for now. I don't think optimizing touchscreen input is sufficiently important on desktop to justify regressing general rAF behavior, but if we have functionality behind a flag we can at least start landing vsync-aligned input changes.
I am now beginning to think that the 'not good' in comment 169 is just high latency mode (issue 465105) rearing its head in a totally different manner due to the new "unified BeginFrame for Aura", because the 'fixes' in that issue (that cause a switch to low latency mode) 'work' to cause Canary to revert back to the normal/expected 1ms OS error in inter-frame times.

But for me, Canary jumps into high latency mode much more quickly than it ever did before.  It is hard for me to reset into low latency mode and keep it there.

Regardless, attached is a trace.
2.4 MB Download
Thanks for the trace. It is definitely a a high latency mode bug, likely caused by a bad deadline in the unified begin frame patch (

The Browser is idle in the trace, so the jitter shouldn't be that bad outside in low-latency mode like I suspected in #170. That said, I did see some extra jitter when the Browser is busy - I will open a separate bug for that.
In the multiple open window situation the (with raF in one window and playing a video in another window) the software sync fallback for raF seems to go uncapped in Version 42.0.2311.135 m (see attached).

So it shoots up to 140-160fps; then on hiding the second window it drops back to a capped 60fps.
14.9 KB View Download
Mozilla are shipping Project Silk (hardware v-sync aligned rendering) with Firefox 40, and the results on my development machine are excellent. The rendering on sbperftest is visually flawless, and most of the time it measures jank at 0.1ms, or even 0ms (to the nearest 0.1ms)!

Canary 44.0.2399.0 is still doing well here, but usually measures around 1ms jank. This seems good, but note that 1ms is still about 6% of the 16.67ms frame budget, so it seems improving this to Firefox's level would still improve its robustness against jank. I hope Chrome is able to match Firefox's v-sync quality.
Comment 176 by Deleted ...@, Jun 11 2015
ITs crazy that this issue still persists. Scrolling in Chrome realy looks terreble, and jerky.
Comment 177 by Deleted ...@, Jun 12 2015
This issue persists for a while now with no solution. Out of the last posts I can't make out whether or not this is still being actively worked on but this is one of these issues that make me think about switching browsers yet again *sigh*.

This issue has great impact on users. Most apparent is it when scrolling compared to scrolling in IE or Firefox which is so incredibly smooth that I'm kinda crying over the mad screen tearing in Chrome, and I scroll a lot. Another issue are the amounts of canvas based browser games. With this issue persisting, it's a pain to play anything in Chrome. Even, a game that has so little graphical features, is almost not playable because of the horrible tear. Currently running Firefox in parallel just for games.

I'm here to bump this so it's not being forgotten because it looks like it was?
Just to be clear with respect to #176/177, are you referring to touch scrolling? Or wheel/keyboard/scrollbar drag scrolling?
Comment 179 by, Jun 12 2015
Just to be clear, this issue has nothing to do with scrolling a webpage or scroll bars, it has to do with redrawing the graphical data on the screen when it is refreshed. If you have issues with scrolling webpages please log a different bug.

Getting correct vsync timing information and delivery the data to the screen at the right time is being worked on. There are a bunch of improvements coming but fixing this problem properly for good on all platforms (and preventing it from occurring) again has been a lot of work because of the complexity of the chrome rendering system and a number of other efforts going on at the same time.

We **are** aiming to make's examples be 100% perfect all the time on Chrome.
Comment 180 by, Jun 12 2015
You might find this tool interesting in that regard:

See some of the attached charts.

31.8 KB View Download
43.9 KB View Download
33.5 KB View Download
I have a 2 monitor setup at work on a Windows 7 64-bit machine running Chrome 43.0.2357.132 m. I noticed tearing on one of my web pages and that led me here. One monitor is connected directly via D-SUB (VGA) to the desktop. The other is connected via Display port to D-SUB adapter (DP on the desktop, D-SUB on the monitor). On the first one there is no tearing on my web page or On the second one the tearing is very noticeable on both.
markst3v3ns: Tearing is very unexpected. Can you open a new bug and include traces on the system with tearing?

Instructions for how to capture a trace:
I would like to add that we are also delaying our game release until this is fixed (
Comment 184 by Deleted ...@, Jul 28 2015
I've tried everything I can to get rid of a v-sync... I could care less on how much cpu/gpu power it uses... I have 3x asus g-sync 2k monitors... capable of up to 144Hz refresh or 120Hz in 3D mode... I stream often to twich 100fps, but I never can figure out how to get the low 60fps v-sync lock to disable... Anyone able to help me??? Also, need higher Max memory... limited to 512MB... I wish for 1 to 1.5GB MAX...

Monitors:3x Asus PG278Q, 1x LG 34UM95
CPU: Intel i7-4790K
RAM: 2x 8GB DDR3 2933MHz

Chrome Version: 45.0.2454.15 beta-m
Labels: Hotlist-GPU-Fixit
Labels: -Hotlist-Scheduling Cr-Blink-Scheduler
Labels: -Cr-Blink-Scheduler Cr-Blink-Scheduling
Comment 188 Deleted
What's our status on this?  I'm asking because this is a highly starred issue, and was started quite long ago.
Comment 190 by, Oct 21 2015
We have landed a bunch of changes which fix things around this area but to fundamentally get this totally finished we need the following things fixed / finished;

 * (done) Actually use the time from BeginFrame information rather than random "Now()" value.
 * (in progress) Unified Begin Frame (make all renderers using the same single source and enable filtering)
 * (in progress) Display Scheduler (provide better scheduling of frames)
 * (unstarted) Back pressure API which means we cleanly drop to 30 fps (see discussion on scheduler dev mailing list).
 * (unstarted) Get better sources of vsync information on individual platforms (see proposal about how to get a really good vsync value on Windows).

We also need to come up with better testing and metrics to prevent any regressions of this problem in the future. I've been discussing with the ChromeOS and input latency testing group on how we can reuse their work to also measure the actual real world experience people are getting.

In summary, "Some progress but still lots to do. We want to solve this properly and for good."

Just to be clear with respect to #176/177, are you referring to touch scrolling? Or wheel/keyboard/scrollbar drag scrolling?
Just noticed that latest canary (49.0.2590.0) once again breaks vsync.

Canary again uses a precise interval of 16.666ms, which results in a Hz of 60.0024 being used -- instead of the Hz of my display.
The new vsync problem (see #192) was introduced between r364188 (works) and r364220 (has problem)

What is the status of VSYNC completely breaking, starting with 49.0.2587.0 (between r364188 and r364220)?

To confirm this new vsync problem, make sure to use a Windows computer with a confirmed vsync Hz *less* than 60Hz (for example, for my computer, the Hz is 59.802Hz).

See attached for what I see at using these two versions.
34.8 KB View Download
36.8 KB View Download
No obvious changes between those two revisions. The only possibility I can see is . Could you attach the about:gpu from Chrome both at r364188 and at r364220? 
jbauman/195: see attached
721 KB Download
1.1 MB Download
zmo@, do you know why might prevent Chrome from using the GPU on an optimus system?
Comment 198 by, Dec 17 2015
I don't think that CL does anything that caused the issue here.

Looking at the both about:gpu info, one thing is in 364220 we only recognize one GPU whereas in 364188 we recognize two?

Another possibility is we could lose GPU because of a cold run.  If you restart chrome again, the issue might just go away because we already cached the GL strings (using the same user-data-dir).
zmo/jbauman: Rerunning Chrome does not fix the problem.  Running with --ignore-gpu-blacklist causes Canary to properly VSYNC.  See attached for an about:gpu using this flag.

There must be some 'significant' change between r364188 and r364220 that is causing Canary to now ignore the GPU on my notebook, which is then causing 'no vsync' (and still not finding/reporting GPU1)?  Please fix under this issue (as no vsync), or if important enough, open a new issue...

1.1 MB Download
zmo/jbauman: Just tested with the latest Canary 49.0.2595.0 (r365973) and the GPU is (mostly) back on (about:gpu attached; stangely canvas is not accellerated) -- but VSYNC is still not working, as per #192.
707 KB Download
zmo/jbauman: new very narrow bisect.  The new VSYNC problem #192 (GPU issue) on my notebook was introduced between r364188 (works) and r364195 (has problem).  Using "--ignore-gpu-blacklist" works around the problem.  This is really narrow now, and the change by 'zmo' seems the only possibility?  Can anyone else take a look and find the problem?

The new problem discussed in #192-#201 has been moved into issue 571241.
Comment 203 by, Dec 19 2015
Blockedon: chromium:571241
Comment 204 by, Dec 21 2015
Something doesn't look right in #200 attached about:gpu

It says in the "Problems Detected" that video decode is software only, but in the Features, actually it says hardware accelerated.  Whereas the situation with canvas is the opposite.
zmo/204: yes, about:gpu is corrupted.  I will provide more details in issue 571241.
Comment 206 by, Feb 24 2016
Comment 207 by, Feb 24 2016

There is a new vsync problem in Chrome Canary, caused by canvas.drawImage().

I can not provide a bisect since issue 571241 prevented me from testing vsync for several months.  Since issue 571241 has just been fixed, I now notice major spikes (missed frames) in inter-frame timings on my notebook (see attached speed-20-pixel.jpg).

The new vsync problem must be caused by canvas.drawImage() (is this due to a change in how images are internally tiled or not?) since the spikes seen in inter-frame timings are directly correlated to the 'Background image' pixel scroll speed at (and turning off drawing the background image, eliminates vsync spikes).  See the attached speed-1-pixel.jpg for when the drawImage() scroll speed is one pixel.

26.4 KB View Download
23.7 KB View Download
Hi Jerry,

Brian is currently on paternity leave until end of April. I'm CCing skyostil as the current master of scheduling to triage. I'm guessing that we probably should have a new bug here too.
That canvas.drawImage() issue seems like it might be unrelated to the actual mechanics of requestAnimationFrame. Would you mind splitting that off into a new bug?

Is there something else left to be fixed here?
skyos/210: "Is there something else left to be fixed here?"  Yes, a lot.  Just some of the outstanding issues are:

There is a pretty glaring initialization problem in Chrome, where Chrome is not at all attempting to VSYC properly, until the Chrome application window is resized (under Windows).  I believe this is related to when Chrome uses Direct3D9Ex, which probably explains why no one there sees this issue?

Chrome is NOT syncing to VSYNC (yet).  On AC power, Chrome appears to be using spin waiting to wait until the correct sub 1-ms time.  On battery power, there is a very noticeable sawtooth pattern in callback timings, due to timer inaccuracy (on battery).  So Chrome+VSYNC+battery is not there yet.  Issue 467617 discloses how Chrome could fix this (and demo/source code was provided to briander..., bajones, sunn... and mit...).

Comment #208 problem still exists.

For me, VSYNC in Chrome/Canary since around Feb 2016 -- is once again broken.  Chrome can not pass the tests at

enne, this change:

    f2d7f5e Turn on enable begin frame scheduling by default

has altered Chrome vsync accuracy behavior.  This appears OK and simply reverts Chrome back to a prior behavior, but this comment is to document side effects of your change.

Before the change (and turning off drawing the background image at to avoid the comment #208 bug), Chrome was nearly perfectly vsync aligned -- but this accuracy was a false gain, as Chrome was spin-waiting for the correct sub 1-ms interval time (see attached before.jpg).  So spin waiting is good for vsync accuracy, but bad for power consumption.

After the 'enable begin frame scheduling' change, Chrome appears to now be back to its previous 1-ms accuracy (see attached after.jpg) behavior on A/C and 4-ms (approx) accuracy on battery (see attached ac2battery.jpg).

Chrome at some point needs to implement the VSYNC fix disclosed in issue 467617, which will trigger VSYNC in Chrome (on Windows) from the actual OS VSYNC trigger, instead of from (inaccurate) OS timers.  It is also important to note that this fix will be very power friendly as well (it does NOT require setting the global Windows timer accuracy lower, which increases power consumption).

I assume you also see these accuracy changes in your testing of Chrome/Windows?

32.7 KB View Download
49.3 KB View Download
67.6 KB View Download
skyos, Chrome fails this new VSYNC test (IE/Firefox pass the test just fine)...

Go to, click on the gear icon, under 'Background image', click on 'Huge'.

The result is that the performance graph appears great -- but the VSYNC indicator shows failure (color) on a periodic basis.

That means that Chrome is rendering frames just fine, but is unable to place those rendered frames in unique display frames.

Is there a reason that none of my recent comments (211/212/213) are being responded to?  It makes it look like this bug/issue is dead (no longer being work on).

Will resources be assigned to fix VSYNC, or not?  Been waiting since Oct 9, 2014.

Firefox beats the pants off of Chrome right now.  See the attached for snapshots of Firefox vs Canary.

The amount of variation in requestAnimationFrame() callback times (vsync scheduling) on battery (Windows) is a problem, with a known easy fix (that is not being implemented).

37.3 KB View Download
70.9 KB View Download
Owner: ----
Status: Available
BeginFrame scheduling goes a long way of bringing some sanity to Chrome's vsync architecture, and is being actively worked on. D3DKMTWaitForVerticalBlankEvent() is an obvious subsequent improvement, but we need to get the basics in first.

I still think #208 should be split off into its own bug since centithreads like this are very hard to follow.

(By the way, I somewhat disagree that we should be aiming to run rAF at exact wall clock intervals. As long as we hit the deadline for the next frame and provide a consistent timestamp parameter to rAF, the user will see a perfectly smooth animation. This gives the browser and the OS some leeway for scheduling things more efficiently.)

(Marking available since I'm not personally working on any aspect of this at the moment.)

> By the way, I somewhat disagree that we should be aiming to run rAF at
> exact wall clock intervals. As long as we hit the deadline for the next
> frame and provide a consistent timestamp parameter to rAF, the user will
> see a perfectly smooth animation. This gives the browser and the OS some
> leeway for scheduling things more efficiently.

What about input, like mouse and touch input, that many animations (games) depends upon?  And how that input interacts with a vsync callback that is varied instead of constant?

If the input delay (time from input until a frame is displayed that acts on that input) is not constant, but varies, that is a noticeable (visible) problem.

#208 is now new issue 631166, and with a bisect (with a 'cache purge' the suspect?).
Thanks for filing and bisecting the new bug!

I agree that input definitely needs to be delivered "in sync" with requestAnimationFrame, and that's indeed things work on Android and very soon on other platforms too. Like rAF, input events also come with timestamps, so it is possible to render a smooth input response despite some small OS scheduling noise.
Chrome fails with Intel HD graphics 3000/4400/5500.  Will others report their results?
When briander... was the owner of this issue, we tried to keep all VSYNC related bugs in this issue.  That has recently changed.  Could we mark this issue as being BLOCKED on these issues:

1. issue 632785 - proper VSYNC is broken (Windows) until Chrome app window is resized

2. issue 631166 - too aggressive GPU cache purge is causing missed frames (VSYNC spikes)

3. issue 467617 - how to dramatically improve Chrome's requestAnimationFrame VSYNC accuracy in Windows

4. issue 465105 - an issue tightly related (Chrome internals) to missed frames (VSYNC issues)

5. issue 464835 - Chrome's 96MB GPU limit is unnecessarily causing missed frames (VSYNC issue).  Fixed by turning off the GPU for canvas!

6. issue 367355 - Chrome's 96MB GPU limit is unnecessarily causing missed frames (VSYNC issue).  Fixed by turning off the GPU for canvas!

It would help us all track all of the issues that are causing VSYNC problems.

Also, can we get a new owner assigned to this issue ASAP?

Chrome is now failing for me under Windows no matter what GPU is being used (Intel/Nvidia/etc).  Even on a top of the line Nvidia GPU with 10GB video memory.  Turning OFF the GPU for canvas causes Chrome to once again pass!


Blockedon: 467617 631166 632785 465105 464835 367355
Components: Internals>GPU
Summary: Chrome fails some tests (was: Chrome 38 busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations)
Another mildly annoyed Chrome user starring this issue.

Labels: -Type-Bug-Regression Type-Bug
This is causing me all sorts of headaches, all of which are compounded by the growing relevance of 4K displays. The ridiculously low hardcoded 96mb gpu cache limit gets eaten up in no time.

Astonishingly, general usage of Microsoft Edge is now noticeably smoother and far more pleasing.
We've seen this issue happen to

We have a similar VSYNC tester at though the is a far more advanced tool that can dive more into low-level subtleties.

Please fix.
I have been battling with this particularly on two 4K displays, two computers i5 and i7, 3 graphics cards the latest was GTX-1060 6Mb.
I have just noticed something that might help...
When the mouse is not over the Browser window everything improves. (with hardware acceleration OFF).
However as soon as I move the focus from another window back to the browser window the tearing/jerky behavior starts up again.  I've turned off smooth scrolling which some people say has worked for them.  
Poor display - Mouse IS over browser.JPG
436 KB View Download
OK display Mouse not over browser.JPG
523 KB View Download
... so I'm now thinking...
How do I watch a movie in full 4K and keep the mouse pointer 'out of view'?
We are getting similar issues after noticing problems for our newest game after chrome failed to produce adequate results for our game IronVice at We are now considering abandoning the browser entirely.
I am also seeing this error.
#228: Would you mind filing a new bug with details on how to reproduce the issue on I just want to make sure we're not conflating issues here.
I updated to the latest version of Chrome and found the 44.0 MP benchmark on to run fine. Can anybody confirm?
With canary at least some of the vsync issues still exist with my intel 5000 integrated graphics. Issues are exacerbated with a second monitor. We have encountered many issues with iron Vice + Chrome. The browser/our users are not ready for that level of 3D to run smoothly on most people's setups (~80+%). I meant to comment on this specific bug effecting IronVice as well. Thanks for the quick response skyos
What's changed?   
The problem seems to be fixed when testing with !
I have Chrome 54.0.2840.99 m
Firefox 50.0.2 seems to be good too.
Issues are the same for me.
Comment 235 Deleted
It looks (from #231 and #233) that at least part of this bug is no longer reproducible. Is this still an open issue and can someone please state exactly what the remaining issues are and what the current status is? Note that this is currently the #4 most starred Blink bug.
I've attached a screenshot of the vsync still having issues with chrome canary. Let me know if you need anymore debugging help. The vsync seems to be mostly ok but has it's ups and downs based on some imperceivable change elsewhere. The vsync errors don't seem to have anything to with the application itself. 
Screen Shot 2017-01-23 at 2.53.53 PM.png
955 KB View Download
Screen Shot 2017-01-23 at 2.55.31 PM.png
64.1 KB View Download
This bug appears to be cured - for me at least.

Comment 233
<> by <>, Dec 7

What's changed?
The problem *seems to be fixed* when testing with !
I have Chrome 54.0.2840.99 m
Firefox 50.0.2 seems to be good too.
I notice that when a FB notification came in you can see on the upper right the graph on the left most side shows a large VSYNC issue. Also on a second monitor the graph is consistently flawed. I can provide a graph for that too if necessary.
Screen Shot 2017-01-23 at 3.15.53 PM.png
588 KB View Download
Comment 240 by, Jan 25 2017
It's broken on my 120Hz monitor. I tried all of these:


And they all sync to 55-57FPS (it constantly "jitters" between values.) Not only on the vsynctester site, but on every site. Including youtube. The result is that all videos stutter, and so does scrolling.

In short, Chrome is broken on Linux when using a low-blur/high-refresh monitor.
Comment 241 Deleted
Re: Comment 240 I have my doubts that it is Chrome's fault that you never reach 120fps. Perhaps one of your processors is too weak. Therefore knowing CPU, GPU, and mainboard model may help. 

Can you check if enabling/disabling hardware acceleration in your Chrome settings makes a difference?
Comment 244 Deleted
Android v-sync accuracy appears to have regressed recently. rAF-driven canvas animations now only run at 50 FPS and look janky. Please see issue 694267
Please consider marking this issue blocking on new issue 694267 (Android vsync regression), and possibly on new issue 694075 (how automated test could detect vsync regressions).
Comment 248 Deleted
Components: Blink>Canvas
Labels: -Needs-Feedback
Adding the canvas label and some folks from the canvas team since this seems to be canvas related.

@Junov so you don't have to re-read the thread:
It looks like Chrome might be dropping frames on periodically. I can get the 'VSYNC' text to flash cyan or blue relatively reliably by quickly dragging my cursor back and forth across the links at the bottom of the page. has a fairly detailed description of what the problem might be.

Could you take a look and see if you can repro?
Comment 250 Deleted
Comment 251 Deleted
Running full screen canvas, jankiness is far less likely to happen than when mixing HTML and canvas.  The canvas element can skip when HTML is updates.  It also happens at when it tries to update the statusbar at bottom.

If you go to and start moving mouse all over the place, you can see fluidity variances as the processing overhead of different page elements (canvas and non-canvas) compete against each other.  Mouseover the hyperlinks, mouseover the tabs, click the pulldown listboxes, and watch what happens to the animation timing -- and how it suddenly stutters at that time.  

Presumably, processing priority is rightfully given to user actions, like mouse control, and this can naturally cause outside-canvas user activity to cause CPU cycles to move away from canvas processing and/or compositing.  Especially if either is done via a slow path (software).

On a related note -- for VSYNC related topics I am now an Invited Expert in W3C Web Platform Working Group, specifically working on a VSYNC API, I'd like your help with W3C HTML Standards discussion on a VSYNC API  -- --

This item in W3C's tracking system discusses an improved future VSYNC API (plus variable refresh rate support, plus VSYNC OFF support, aka Javascript access to Chrome's --disable-gpu-vsync command line option)
Assigning to someone from the canvas team to take a look. @Junov - we're trying to get a concrete next action (along with a NextAction date) for the top 1% of starred bugs. 

Could you take a look at this bug and identify what the next step to resolve it would be, along with when we might be able to make that progress?
Please remove me from this thread I am sick of getting emails for it and
cannot figure out how to do it myself thanks
@#253: There is concrete work in progress for resolving this issue
ericrk@ is working on a GPU memory management framework that will help drawImage performance by allowing us to remove the GPU texture cache limit.
stanisc@ is working on a VSYNC infrastructure to improve the synchronization of animations the the display hardware.
Sign in to add a comment