New VSYNC problem caused by drawImage()?
Reported by jer...@duckware.com, Jul 25 2016
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Steps to reproduce the problem: 1. Visit www.vsynctester.com using a Win7 computer, where chrome://gpu shows "Direct3D9Ex" 2. Notice the spikes in vsync graph What is the expected behavior? the vsync graph should be 'flat' (no spikes). What went wrong? When the 'background image' option on vsynctester.com is checked (caused drawImage calls), vsync is busted, on a periodic basis (see attached speed-20-pixels.jpg). When the 'background image' option is not checked (turns drawImage off), vsync (mostly) works. The speed at which the background image is scrolled changes the frequency of the vsync spikes. I can not bisect since issue 571241 turned off my gpu for several months. Did this work before? Yes See https://bugs.chromium.org/p/chromium/issues/detail?id=422000#c208 Chrome version: 52.0.2743.82 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0
Jul 25 2016,
OK, tried another bisect and made progress. On Win7 using Direct3D9Ex, vsynctester.com vsync line is flat in r364106 and spikes in r364117. Changes were: https://chromium.googlesource.com/chromium/src/+log/e4972a2857d0dc1b4653c752dfc2c7591430b888..e92c4096de6e0b7761e4e97850245948878c0446 with the skia rollup suspect: https://chromium.googlesource.com/chromium/src/+/da8b0d476ac27f7edf9dbe5da93e748bfa6e1d18 What stands out is: 9f0337e Attempt to land cache purge again [and regen bot logs if still failing]
Jul 26 2016,
Jul 27 2016,
Jul 27 2016,
Triaging and assigning to bsalomon@ as per bisect result from C#1 for further investigation and more inputs on this.
Jul 27 2016,
Jul 30 2016,
bsalomon, (1) Just replicated on a Win 8.1 computer, where Chrome is using D3D11 (but you must resize the Chrome app window first -- see issue 632785 ). (2) 'huge' option at vsynctester.com has been renamed 'large'. (3) At vsynctester.com, turn off 'preview' under 'background image' to work around another chrome bug.
Aug 1 2016,
Aug 3 2016,
Heads up that bsalomon is out this week, so debug on our side may be a bit quiet.. adding some labels and other folks.
Aug 3 2016,
[was comment 8, fixed a typo; thanks for heads up on bsalomon] New test procedure that might help to replicate the problem faster: 1. Visit vsynctester.com and click on gear icon 2. Under 'background image', turn 'preview' off and set MP/megapixels to 5 3. inter-frame graph should have no (big) spikes 4. increase MP by 1, and repeat, until you see a regular (big) spike pattern in the inter-frame graph 5. Under 'background image', turn 'preview' ON, and big spikes go away Using this new procedure, I replicated the problem on multiple systems -- and all caused by some change between r364106 and r364117, with the "kDefaultMaxUnusedFlushes=64" the suspect.
Aug 29 2016,
If a timely fix is not coming, please revert the change (see comment 1) that is causing this problem.
Aug 30 2016,
likely problem change: https://codereview.chromium.org/1510103002
Sep 5 2016,
Since Chrome 53, CSS transitions/animations have been terrible on my laptop, with constant jerkiness, despite everything being a silky smooth 200fps when vsync is disabled with -disable-gpu-vsync. I think this might be the same issue that I am seeing, my apologies if my bug is a dupe: https://bugs.chromium.org/p/chromium/issues/detail?id=643241
Sep 7 2016,
bsalomon@, can we get a status update on this issue from you?
Sep 8 2016,
I'm starting on an implementation of a fix for this today. It may not be ready until next week.
Sign in to add a comment