Issue 422000 in chromium: Chrome 38 busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Bug-Regression OS-Windows

New issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync" and causes
jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 http://www.duckware.com/test/chrome/jerky3.html
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.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #8 on issue 422000 by m...@goodboydigital.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #9 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #10 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@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:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=91

which ALWAYS returns false:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gfx/frame_time.h&l=34

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:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=84

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


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=99

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 http://www.duckware.com/test/chrome/vsync.html (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:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=127

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:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=130

---------

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:


https://code.google.com/p/chromium/codesearch#chromium/src/ui/gl/gl_surface_win.cc&l=135

[chro...@googlecode.com]

Updates:
Owner: baj...@chromium.org

Comment #13 on issue 422000 by brian...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #15 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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:

http://www.duckware.com/test/chrome/jerkychromevsie.mp4

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.

[chro...@googlecode.com]

Updates:
Cc: msrchan...@chromium.org le...@chromium.org esp...@chromium.org
jchaf...@chromium.org

Comment #16 on issue 422000 by wangx...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Issue 421235 has been merged into this issue.

[chro...@googlecode.com]

Comment #22 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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).

[chro...@googlecode.com]

Comment #25 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Chrome 37 works much better because it uses a "timebase" (but with an
incorrect interval) Chrome 38 is busted because it uses a
random "timebase" (zero). When "timebase" in traces goes from valid to
zero, you have absolutely found the cause. See #10 above and this:

{"timebase":0.0,"interval":0.016666}

[chro...@googlecode.com]

Comment #26 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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]

[chro...@googlecode.com]

Comment #27 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?

[chro...@googlecode.com]

Comment #28 on issue 422000 by idyllren...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

> #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.

[chro...@googlecode.com]

Comment #30 on issue 422000 by bugdro...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations

https://code.google.com/p/chromium/issues/detail?id=422000#c30

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/10b6709e59abc1ef5d3921a38b93acd73a689be8

commit 10b6709e59abc1ef5d3921a38b93acd73a689be8
Author: bajones <baj...@chromium.org>
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.

BUG=422000

Review URL: https://codereview.chromium.org/668273003

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

[modify]
https://chromium.googlesource.com/chromium/src.git/+/10b6709e59abc1ef5d3921a38b93acd73a689be8/ui/gfx/frame_time.h
[modify]
https://chromium.googlesource.com/chromium/src.git/+/10b6709e59abc1ef5d3921a38b93acd73a689be8/ui/gl/gl_surface_win.cc

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #31 on issue 422000 by baj...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Cc: mit...@mithis.com

Comment #32 on issue 422000 by mit...@mithis.com: Chrome 38 busts "vsync"

[chro...@googlecode.com]

Comment #33 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?

[chro...@googlecode.com]

Comment #36 on issue 422000 by NISSAN4...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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
clear_uniforms_before_first_program_use
exit_on_context_lost
scalarize_vec_and_mat_constructor_args
texsubimage2d_faster_than_teximage2d
use_current_program_after_successful_link
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 9.18.13.4448
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
Diagnostics
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)
szDriverAssemblyVersion 9.18.13.4448
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:9.18.13.4448:pci\ven_10de&dev_1183
szDriverSignDate
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
szMonitorMaxRes
szMonitorName Dell U2311H(Digital)
szNotesEnglish No problems found.
szNotesLocalized No problems found.
szOverlayEnglish Supported
szRankOfInstalledDriver 00DA2001
szRegHelpText
szRevision
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.

[chro...@googlecode.com]

Comment #37 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.


Attachments:
gpu-fails.pdf 1010 KB

[chro...@googlecode.com]

Updates:
Labels: Needs-Feedback

Comment #38 on issue 422000 by rponn...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Tested this issue on Windows7 using: 40.0.2202.3 with below steps:

1. Opened http://www.duckware.com/test/chrome/jerky3.html
2. Observed FAIL in Red colored some times.

Could you please confirm the behavior and provide more TESTS to verify this
issue.

[chro...@googlecode.com]

Comment #39 on issue 422000 by rponn...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Attaching screen-cast & chrome:// gpu used in commnet38#

Attachments:
422000.mp4 1.4 MB
gpu.html 83.9 KB

[chro...@googlecode.com]

Comment #40 on issue 422000 by rponn...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Here is the trace info:
https://docs.google.com/a/google.com/file/d/0B3isupAZQR_xOUtkU0Z1MTdfOEE/edit

[chro...@googlecode.com]

Comment #43 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

Attachments:
crgpumain-with-chromes-raf-implementation.jpg 66.0 KB
crgpumain-with-my-raf-implementation.jpg 57.4 KB

[chro...@googlecode.com]

Comment #48 on issue 422000 by mit...@mithis.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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).

[chro...@googlecode.com]

Comment #50 on issue 422000 by ashlaa...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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:
https://www.scirra.com/forum/about-the-jerkiness-on-the-movement_t117554

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.

[chro...@googlecode.com]

Comment #51 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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).

https://www.scirra.com/forum/about-the-jerkiness-on-the-movement_t117554

[chro...@googlecode.com]

Comment #52 on issue 422000 by mit...@mithis.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

BTW This issue is unrelated to issues with the timestamp that RAF is given
(which I'm working on fixing).

[chro...@googlecode.com]

Comment #53 on issue 422000 by serg...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Issue 425593 has been merged into this issue.

[chro...@googlecode.com]

Comment #56 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?

[chro...@googlecode.com]

Comment #57 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

FYI: A revised and updated jerky3.html test has landed at
http://www.vsynctester.com/

[chro...@googlecode.com]

Comment #58 on issue 422000 by bugdro...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations

https://code.google.com/p/chromium/issues/detail?id=422000#c58

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be

commit 0d49051cb119a5fad0f8291834fd93d0225f39be
Author: bajones <baj...@chromium.org>
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 https://codereview.chromium.org/708483003/)

Reason for revert:
Possibly introduced regressions into smoothness.tough_scrolling_cases

https://code.google.com/p/chromium/issues/detail?id=431599

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: https://crrev.com/3f72599ead7c0ee7922afedf93ffae17f5f45f88
> Cr-Commit-Position: refs/heads/master@{#303074}

TBR=brian...@chromium.org,jba...@chromium.org,k...@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=422000

Review URL: https://codereview.chromium.org/710393003

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

[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/content/common/gpu/image_transport_surface.cc
[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/ui/gl/gl_context_egl.cc
[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/ui/gl/gl_surface.cc
[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/ui/gl/gl_surface.h
[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/ui/gl/gl_surface_egl.cc
[modify]
https://chromium.googlesource.com/chromium/src.git/+/0d49051cb119a5fad0f8291834fd93d0225f39be/ui/gl/gl_surface_egl.h

[chro...@googlecode.com]

Comment #59 on issue 422000 by mit...@mithis.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

jerryj, could you attach your updated vsync test? The previous versions
have been really useful.

Thanks!

[chro...@googlecode.com]

Comment #60 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

mit..., the updated vsync test (vsynctester.com) 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).


Attachments:
vsynctester.zip 2.3 MB

[chro...@googlecode.com]

Comment #61 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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).

Attachments:
41.0.2219.jpg 27.8 KB

[chro...@googlecode.com]

Comment #63 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 is never correct on startup, whether windowed or
maximized.

Version 41.0.2225.0 canary (64-bit)

[chro...@googlecode.com]

Comment #64 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #66 on issue 422000 by just1mor...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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...!

[chro...@googlecode.com]

Comment #67 on issue 422000 by just1mor...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

I have updated my test (link =
https://dl.dropboxusercontent.com/u/184657779/C2_demos/GPUload/index.html )
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.

Attachments:
chrome canary 41.png 10.1 KB

[chro...@googlecode.com]

Comment #68 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

While resizing Canary's window fixes the VSYNC issue, the 'resize'
interestingly causes 'on battery' problems. See issue #439751.

[chro...@googlecode.com]

Comment #69 on issue 422000 by kiris3...@hotmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 ?

[chro...@googlecode.com]

Comment #70 on issue 422000 by NISSAN4...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #71 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

bajones, can you provide a status update on this issue?

[chro...@googlecode.com]

Comment #73 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

bajones, the fix in #72 (https://codereview.chromium.org/749483002) suffers
from the same bug reported in #62 -- that VSYNC in Chrome is BUSTED until
the Chrome application window is resized.

[chro...@googlecode.com]

Comment #74 on issue 422000 by ashlaa...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

With the latest patch Canary is very smooth for me. Using this test:
http://www.scirra.com/demos/c2/sbperftest/

Jank is around ~2ms and max jank is <4ms which is excellent - doesn't
appear to drop a single frame.

[chro...@googlecode.com]

Comment #75 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #76 on issue 422000 by just1mor...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

I have yet to see an improvement with this. Attached is an image from my
test
https://dl.dropboxusercontent.com/u/184657779/C2_demos/GPUload/index.html
on the latest canary. There's a marked vsync spike at approx 20 ms - which
guarantees missed frames at 60 fps.

Attachments:
20150122_Version 42.0.2283.5 canary 64-bit.png 6.7 KB

[chro...@googlecode.com]

Comment #77 on issue 422000 by just1mor...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

...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.

[chro...@googlecode.com]

Comment #79 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Canary 42.0.2287.0 is now completely unstable. requestAnimationFrame()
callbacks are now all over the place.

Something changed (for the worse).

[chro...@googlecode.com]

Comment #80 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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
www.vsynctester.com

See attached canary-42.0.2292.0.jpg to see a very bad test using Canary and
www.vsynctester.com -- that shows that the latest Canary is very busted.

Attachments:
chrome-40.0.2214.93.jpg 165 KB
canary-42.0.2292.0.jpg 197 KB

[chro...@googlecode.com]

Comment #81 on issue 422000 by ashlaa...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

http://www.scirra.com/demos/c2/sbperftest/ 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.

[chro...@googlecode.com]

Comment #82 on issue 422000 by thunder...@illyriad.co.uk: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Related? https://code.google.com/p/chromium/issues/detail?id=451670

[chro...@googlecode.com]

Comment #83 on issue 422000 by sizzga...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Almost half a year, and still no improvement over IE ?

[chro...@googlecode.com]

Comment #84 on issue 422000 by fldrga...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

why dont you fix this?

[chro...@googlecode.com]

Comment #85 on issue 422000 by kevindatapaw: Chrome 38 busts "vsync" and

causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Well, the number of votes almost tripled over the past few days. I think
it's a sign.

[chro...@googlecode.com]

Comment #86 on issue 422000 by ashlaa...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Mozilla's Project Silk sounds like the right kind of solution to this
problem: https://hacks.mozilla.org/2015/01/project-silk/ They describe how
hardware vsync timers are more reliable and provide better performance than
software timers. Maybe this is what Chromium needs as well?

[chro...@googlecode.com]

Comment #87 on issue 422000 by seedpr...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Firefox might be a mess now, but project silk looks to be a vast
improvement that should bring FF the kind of stability we see on Windows
with IE 11. Why re-invent the wheel?

[chro...@googlecode.com]

Comment #88 on issue 422000 by szym...@prokonto.pl: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

It seems that Google doesn't care about HTML5 games at all. Even Microsoft
Internet Exploder is 100x better than Chrome.

[chro...@googlecode.com]

Comment #89 on issue 422000 by pya...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #91 on issue 422000 by ashlaa...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Is Chromium's rendering driven by a hardware v-sync timer or a software
timer?

[chro...@googlecode.com]

Comment #98 on issue 422000 by jer...@duckware.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

bajones/#97 - normal .ZIP file please...

[chro...@googlecode.com]

Comment #99 on issue 422000 by baj...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Zip file of the build from #97, for those that prefer it:
https://drive.google.com/file/d/0BzudLt22BqGRbHhOc280VHVObk0/view?usp=sharing

[chro...@googlecode.com]

Comment #101 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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
http://www.vsynctester.com 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).

Attachments:
gpu.html 87.0 KB

[chro...@googlecode.com]

Comment #103 on issue 422000 by face...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

First off, thanks for looking into this!

Ran tests with both flags at : http://www.vsynctester.com/

--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.

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

about:gpu attached


Attachments:
gpu.html 4.3 KB

[chro...@googlecode.com]

Comment #105 on issue 422000 by briander...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@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.

[chro...@googlecode.com]

Comment #106 on issue 422000 by thunder...@illyriad.co.uk: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?
https://code.google.com/p/chromium/issues/detail?id=153139

[chro...@googlecode.com]

Comment #107 on issue 422000 by Joedo...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@#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.

Attachments:
gpu.html 139 KB

[chro...@googlecode.com]

Comment #108 on issue 422000 by ashlaa...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Tested on another system (a high end desktop):

--hardware-vsync-only

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


--software-vsync-only

sbperftest: generally smooth, about the same as with hardware vsync
vsynctester.com: 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.

Attachments:
gpu.html 136 KB

[chro...@googlecode.com]

Comment #109 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 www.vsynctester.com. 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 www.vsynctester.com 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 www.vsynctester.com web
site at a very small zoom factor (like around 25%).

(5) When the vsynctester.com 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...

[chro...@googlecode.com]

Comment #110 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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

[chro...@googlecode.com]

Comment #112 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@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)?

[chro...@googlecode.com]

Comment #113 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@jerry

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
seconds...it 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.

[chro...@googlecode.com]

Comment #114 on issue 422000 by face...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@TiAmIsT/113 (1&2) I am experiencing this as well - "The actions that cause
motion stuttering on any build."

[chro...@googlecode.com]

Comment #115 on issue 422000 by face...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@TiAmIsT/113 (1&2) I am experiencing this as well - "The actions that cause

motion stuttering in all tested versions of chrome, including stable:"

[chro...@googlecode.com]

Comment #116 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Here is a video of what I see running www.vsynctester.com against "Version
42.0.2294.0 canary" (the new VSYNC bug introduced between r312868 and
r312958):

http://www.duckware.com/test/chrome/vid/vsync-busted-42.0.2294.0.mp4

[chro...@googlecode.com]

Comment #118 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 ######@duckware.com, where
###### is the number of this issue.

[chro...@googlecode.com]

Comment #119 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@jerryj

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.

[chro...@googlecode.com]

Comment #123 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@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.

[chro...@googlecode.com]

Comment #124 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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:

https://chromium.googlesource.com/chromium/src/+/48bd0e24c5c66e0334afcd2921e355799fa15e9f

...and also the update to skia in r312918:

https://chromium.googlesource.com/chromium/src/+/c742ea924974388a15ef160e82e3f0b7895d5dc8

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.

[chro...@googlecode.com]

Comment #125 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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 bajones bisect of r312916/r312924, but when I

[chro...@googlecode.com]

Comment #126 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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

[chro...@googlecode.com]

Comment #127 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Observed results:

vsynctester.com:

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 -- http://www.scirra.com/demos/c2/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 ;)

[chro...@googlecode.com]

Comment #128 on issue 422000 by pya...@gmail.com: Chrome 38 busts "vsync"

and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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).

[chro...@googlecode.com]

Comment #129 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@bajones: It is clear from looking at the F12 timeline while running
www.vsynctester.com in r312916 (works) vs r312924 (fails) that there was
some major regression in the graphics subsystem. See attached captures.


Attachments:
312916.jpg 107 KB
312924.jpg 115 KB

[chro...@googlecode.com]

Comment #130 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

@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).

[chro...@googlecode.com]

Comment #131 on issue 422000 by ashlaa...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #132 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?

[chro...@googlecode.com]

Comment #133 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #134 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

[chro...@googlecode.com]

Comment #135 on issue 422000 by ashlaa...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

42.0.2299.0 canary is looking good here. Both JS measurements and visual
appearance are good.

[chro...@googlecode.com]

Comment #136 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #139 on issue 422000 by seedpr...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #140 on issue 422000 by TiAmIsT...@gmail.com: Chrome 38

[chro...@googlecode.com]

Comment #141 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

Here is a video showing the VSYNC problem stated in #138 (also a correction
to that post, change 'render' to 'inter-frame')

http://www.duckware.com/test/chrome/vid/canary-43.0.2321.0.mp4

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).

[chro...@googlecode.com]

Comment #142 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

new issue, but appears strongly related to the VSYNC issues...

Canary has some significant delays from the time the internal timer wakes
up, until the time that the requestAnimationFrame callback is called. With
Canary, run with this:

function rafCallback( tTime ) {
var tLate = performance.now-tTime;
...
}

and the result is the attached canary-late.jpg (also now the
vsynctester.com 'late' checkbox). The fact that this 'late' line is no
longer near zero like it is for Chrome release (see attached
chrome-late.jpg) suggests that Canary is performing some spin-waiting or
something similar -- But (1) the time passed to the rAF callback needs to
double checked and (2) the spikes (over 4ms) in how late the rAF callback
is called is highly suspicious.


Attachments:
canary-late.jpg 53.4 KB
chrome-late.jpg 34.8 KB

[chro...@googlecode.com]

Comment #143 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

[FYI: deleted last comment, moved to new issue 464740]

[chro...@googlecode.com]

Comment #144 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

www.vsynctester.com 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).

[chro...@googlecode.com]

Comment #145 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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?

Attachments:
chrome-43-0-2332-4.jpg 128 KB

[chro...@googlecode.com]

Comment #146 on issue 422000 by baj...@chromium.org: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

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.

[chro...@googlecode.com]

Comment #151 on issue 422000 by ODensm...@gmail.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

I've recently discovered anomalous Chrome performance issues that may
relate to this issue.

History: http://agentscript.org is an Agent Based Modeling system porting
NetLogo (https://ccl.northwestern.edu/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
http://backspaces.net/temp/ASversions/
To run, for example, the earliest "ants" model, use:
http://backspaces.net/temp/ASversions/as13.16.06/models/ants.html
(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 (http://www.simtable.com/)

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
06/16/13
ants: 8 25 30 58
diffusion: 78/30 77/31 59/31 75/31
fire: 46 48 46 56
flock: broke 5 14 26
12/08/14
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
02/22/15*
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
current**
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 http://agentscript.org 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

[chro...@googlecode.com]

Comment #155 on issue 422000 by jer...@duckware.com: Chrome 38

busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations
https://code.google.com/p/chromium/issues/detail?id=422000

lo.../154, no, —disable-d3d11 does not help.