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
Owner:
Last visit > 30 days ago
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

Blocking:
issue 422000



Sign in to add a comment

New VSYNC problem caused by drawImage()?

Reported by jer...@duckware.com, 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 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
 
speed-20-pixels.jpg
26.4 KB View Download
speed-1-pixel.jpg
23.7 KB View Download

Comment 1 by jer...@duckware.com, 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]

Comment 2 by bsalo...@google.com, Jul 26 2016

Cc: bsalomon@chromium.org
Components: Internals>Skia

Comment 4 by ajha@chromium.org, Jul 27 2016

Cc: -bsalomon@chromium.org ajha@chromium.org
Labels: -Pri-2 M-54 hasbisect Pri-1
Owner: bsalomon@chromium.org
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 jer...@duckware.com, Jul 27 2016

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.



Comment 6 by jer...@duckware.com, 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.
Blocking: 422000

Comment 8 Deleted

Comment 9 by hcm@chromium.org, Aug 3 2016

Cc: robertphillips@chromium.org jvanverth@chromium.org
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 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.
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 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.

Sign in to add a comment