New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 631166 link

Starred by 15 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Sep 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

issue 422000

Sign in to add a comment

New VSYNC problem caused by drawImage()?

Reported by, Jul 25 2016

Issue description

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

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
26.4 KB View Download
23.7 KB View Download

Comment 1 by, Jul 25 2016

OK, tried another bisect and made progress.  On Win7 using Direct3D9Ex, vsync line is flat in r364106 and spikes in r364117.  Changes were:

with the skia rollup suspect:

What stands out is:

9f0337e Attempt to land cache purge again [and regen bot logs if still failing]

Comment 2 by, Jul 26 2016

Components: Internals>Skia

Comment 4 by, Jul 27 2016

Labels: -Pri-2 M-54 hasbisect Pri-1
Status: Assigned (was: Unconfirmed)
Triaging and assigning to bsalomon@ as per bisect result from C#1 for further investigation and more inputs on this.

Comment 5 by, Jul 27 2016

bsalomon, more info...

If you look at the JavaScript source, you will see a reference to  issue 315025 , which is now  issue 367355 .  When I change the source to always do the "ctx.drawImage(i,0,0,1,1);" (bug fix) on every iteration (instead of just at the beginning), most of the vsync spikes seen in this issue go away (except for one).  This strongly suggests that the GPU cache is involved in this issue?

Also, at, under the "Background image" option, there is a "huge" checkbox.  If you are unable to see the spike mentioned in this issue with the standard background image, checking that option may hopefully reveal spikes for you.

Comment 6 by, 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 has been renamed 'large'.  (3) At, turn off 'preview' under 'background image' to work around another chrome bug.
Blocking: 422000

Comment 8 Deleted

Comment 9 by, Aug 3 2016

Labels: Hotlist-Ganesh
Heads up that bsalomon is out this week, so debug on our side may be a bit quiet.. adding some labels and other folks.
[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 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.

If a timely fix is not coming, please revert the change (see comment 1) that is causing this problem.
likely problem change:
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:
bsalomon@, can we get a status update on this issue from you?
I'm starting on an implementation of a fix for this today. It may not be ready until next week.
Status: Fixed (was: Assigned)
I forgot to close the loop here. This was fixed by reworking the system for reclaiming textures that haven't been recently used. Performance at using a 5MP image is smooth (though that may currently be masked by  issue 651517 ).
Confirmed the fix appears in r420485 (  Thanks.

Sign in to add a comment