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]

Triaging and assigning to bsalomon@ as per bisect result from C#1 for further investigation and more inputs on this.

bsalomon, more info...

If you look at the vsynctester.com JavaScript source, you will see a reference to  issue 315025 , which is now  issue 367355 .  When I change the vsynctester.com 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 vsynctester.com, 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 vsynctester.com background image, checking that option may hopefully reveal spikes for you.

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.

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

If a timely fix is not coming, please revert the change (see comment 1) that is causing this problem.

likely problem change: https://codereview.chromium.org/1510103002

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

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.

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 vsynctester.com using a 5MP image is smooth (though that may currently be masked by  issue 651517 ).

Confirmed the fix appears in r420485 (https://codereview.chromium.org/2361093002).  Thanks.