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

Issue 422000 link

Starred by 749 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug


Sign in to add a comment

Chrome fails some vsynctester.com tests

Reported by jer...@duckware.com, Oct 9 2014

Issue description

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.
 
Showing comments 166 - 265 of 265 Older
Would someone from the Chromium team be so kind as to give a brief overview of what the status of this issue is and what kind of work is being done on it? From what I can see it is not a simple fix and requires architectural changes, since the issue has been open for about 6 months now and does not yet appear to be resolved.

This issue is of great concern to users of our HTML5 game engine (www.scirra.com), as it can make HTML5 games compare unfavourably with native games. For months the perception has been building that Chrome can't play HTML5 games smoothly and that this is a major disadvantage of HTML5 compared to native. This seems to be doing a lot to detract from Google's claims that a jank-free, native-quality experience on the web can be achieved. It definitely can be achieved, as demonstrated by browsers like IE11 which appear to have flawless v-sync scheduling. It's also very frustrating as developers to pour effort in to making an effectively jank-free engine, and then it still looks like it janks because Chrome inexplicably drops three consecutive frames; meanwhile your developer evangelists are out talking a lot about how important it is to reach 60 FPS.

Anything that Google can do to alleviate increasingly serious worries that developers have about Chrome's ability to render smoothly at v-sync rate would be considerably appreciated. Ideally someone could give us a rough idea of the architectural changes being made, and an ETA when this issue is expected to finally be resolved.
Also if anyone from Google wants to get in touch to co-operate more closely on this please feel free to reach out to me at ashley@scirra.com.
I was investigating vsync issues on Windows recently and I found that certain applications can cause frame skips in chrome. One such application is flu.x which is used to control the color temperature of the monitor based on time of day. You might see frame drops at regular intervals if you're using such applications. Here's a detailed analysis of the problem: http://make-aitee-work.blogspot.com/2014/02/diagnose-frame-skips-and-stutter-in.html

I was able to confirm this problem using flux where a frame would be skipped every 10 seconds or so on chrome using a single window.
The latest Canary (44.0.2392.0) has done something.  VSYNC is now busted again.
notgood.jpg
80.3 KB View Download
Cc: jdduke@chromium.org simonh...@chromium.org
Owner: briander...@chromium.org
Assigning to self since Brandon already did his part on this bug.

+simonhong since the "unified BeginFrame for Aura" patch (https://codereview.chromium.org/1016033006) definitely added noise to the graph.

Depending on how bad the jitter is, maybe we should have the unified BeginFrame work land behind a flag while we work on making it more responsive and integrating it with the rest of the system.

After the patch above, the rAF start can be blocked by work on the Browser's UI thread which is where the jitter is coming from. This isn't necessarily bad though since going through the Browser's UI thread also allows us to avoid races with user input, which can actually improve perceived smoothness; but we haven't yet integrated with jdduke's work to get that benefit.

Unified BeginFrame should also become more responsive as we move work off the Browser's UI thread with efforts like impl-side-painting in the Browser. We should probably see if there's anything else monopolizing the UI thread and what we can do about it (blink scheduler on the UI thread?).
Can we get a trace of the case where vsync is broken (from Canary)? 

If vsync isn't consistent under low stress and/or relatively idle cases, landing behind a flags seems reasonable for now. I don't think optimizing touchscreen input is sufficiently important on desktop to justify regressing general rAF behavior, but if we have functionality behind a flag we can at least start landing vsync-aligned input changes.
I am now beginning to think that the 'not good' in comment 169 is just high latency mode (issue 465105) rearing its head in a totally different manner due to the new "unified BeginFrame for Aura", because the 'fixes' in that issue (that cause a switch to low latency mode) 'work' to cause Canary to revert back to the normal/expected 1ms OS error in inter-frame times.

But for me, Canary jumps into high latency mode much more quickly than it ever did before.  It is hard for me to reset into low latency mode and keep it there.

Regardless, attached is a trace.
trace.zip
2.4 MB Download
Thanks for the trace. It is definitely a a high latency mode bug, likely caused by a bad deadline in the unified begin frame patch (https://codereview.chromium.org/1121233005/)

The Browser is idle in the trace, so the jitter shouldn't be that bad outside in low-latency mode like I suspected in #170. That said, I did see some extra jitter when the Browser is busy - I will open a separate bug for that.
In the multiple open window situation the (with raF in one window and playing a video in another window) the software sync fallback for raF seems to go uncapped in Version 42.0.2311.135 m (see attached).

So it shoots up to 140-160fps; then on hiding the second window it drops back to a capped 60fps.
Capture.PNG
14.9 KB View Download
Mozilla are shipping Project Silk (hardware v-sync aligned rendering) with Firefox 40, and the results on my development machine are excellent. The rendering on sbperftest is visually flawless, and most of the time it measures jank at 0.1ms, or even 0ms (to the nearest 0.1ms)!

Canary 44.0.2399.0 is still doing well here, but usually measures around 1ms jank. This seems good, but note that 1ms is still about 6% of the 16.67ms frame budget, so it seems improving this to Firefox's level would still improve its robustness against jank. I hope Chrome is able to match Firefox's v-sync quality.

Comment 176 by Deleted ...@, Jun 11 2015

ITs crazy that this issue still persists. Scrolling in Chrome realy looks terreble, and jerky.

Comment 177 by Deleted ...@, Jun 12 2015

This issue persists for a while now with no solution. Out of the last posts I can't make out whether or not this is still being actively worked on but this is one of these issues that make me think about switching browsers yet again *sigh*.

This issue has great impact on users. Most apparent is it when scrolling compared to scrolling in IE or Firefox which is so incredibly smooth that I'm kinda crying over the mad screen tearing in Chrome, and I scroll a lot. Another issue are the amounts of canvas based browser games. With this issue persisting, it's a pain to play anything in Chrome. Even agar.io, a game that has so little graphical features, is almost not playable because of the horrible tear. Currently running Firefox in parallel just for games.

I'm here to bump this so it's not being forgotten because it looks like it was?
Just to be clear with respect to #176/177, are you referring to touch scrolling? Or wheel/keyboard/scrollbar drag scrolling?

Comment 179 by mit...@mithis.com, Jun 12 2015

Just to be clear, this issue has nothing to do with scrolling a webpage or scroll bars, it has to do with redrawing the graphical data on the screen when it is refreshed. If you have issues with scrolling webpages please log a different bug.

Getting correct vsync timing information and delivery the data to the screen at the right time is being worked on. There are a bunch of improvements coming but fixing this problem properly for good on all platforms (and preventing it from occurring) again has been a lot of work because of the complexity of the chrome rendering system and a number of other efforts going on at the same time.

We **are** aiming to make jerryj@duckware.com's examples be 100% perfect all the time on Chrome.

Comment 180 by pya...@gmail.com, Jun 12 2015

You might find this tool interesting in that regard: http://codeflow.org/issues/timing

See some of the attached charts.


google-chrome-windows-rising-load.png
31.8 KB View Download
chrome-osx-rising.png
43.9 KB View Download
chrome-nofinish.png
33.5 KB View Download
I have a 2 monitor setup at work on a Windows 7 64-bit machine running Chrome 43.0.2357.132 m. I noticed tearing on one of my web pages and that led me here. One monitor is connected directly via D-SUB (VGA) to the desktop. The other is connected via Display port to D-SUB adapter (DP on the desktop, D-SUB on the monitor). On the first one there is no tearing on my web page or vsynctester.com. On the second one the tearing is very noticeable on both.
markst3v3ns: Tearing is very unexpected. Can you open a new bug and include traces on the system with tearing?

Instructions for how to capture a trace: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
I would like to add that we are also delaying our game release until this is fixed (titansoftime.com).

Comment 184 by Deleted ...@, Jul 28 2015

I've tried everything I can to get rid of a v-sync... I could care less on how much cpu/gpu power it uses... I have 3x asus g-sync 2k monitors... capable of up to 144Hz refresh or 120Hz in 3D mode... I stream often to twich 100fps, but I never can figure out how to get the low 60fps v-sync lock to disable... Anyone able to help me??? Also, need higher Max memory... limited to 512MB... I wish for 1 to 1.5GB MAX...


Monitors:3x Asus PG278Q, 1x LG 34UM95
GPU: Asus STRIX GTX 980 4GB-RAM
CPU: Intel i7-4790K
RAM: 2x 8GB DDR3 2933MHz

Chrome Version: 45.0.2454.15 beta-m
Labels: Hotlist-GPU-Fixit
Labels: -Hotlist-Scheduling Cr-Blink-Scheduler
Labels: -Cr-Blink-Scheduler Cr-Blink-Scheduling

Comment 188 Deleted

What's our status on this?  I'm asking because this is a highly starred issue, and was started quite long ago.

Comment 190 by mit...@mithis.com, Oct 21 2015

We have landed a bunch of changes which fix things around this area but to fundamentally get this totally finished we need the following things fixed / finished;

 * (done) Actually use the time from BeginFrame information rather than random "Now()" value.
 * (in progress) Unified Begin Frame (make all renderers using the same single source and enable filtering)
 * (in progress) Display Scheduler (provide better scheduling of frames)
 * (unstarted) Back pressure API which means we cleanly drop to 30 fps (see discussion on scheduler dev mailing list).
 * (unstarted) Get better sources of vsync information on individual platforms (see jerryj@duckware.com proposal about how to get a really good vsync value on Windows).

We also need to come up with better testing and metrics to prevent any regressions of this problem in the future. I've been discussing with the ChromeOS and input latency testing group on how we can reuse their work to also measure the actual real world experience people are getting.

In summary, "Some progress but still lots to do. We want to solve this properly and for good."

Just to be clear with respect to #176/177, are you referring to touch scrolling? Or wheel/keyboard/scrollbar drag scrolling?
http://www.wdfshare.com
Just noticed that latest canary (49.0.2590.0) once again breaks vsync.

Canary again uses a precise interval of 16.666ms, which results in a Hz of 60.0024 being used -- instead of the Hz of my display.
The new vsync problem (see #192) was introduced between r364188 (works) and r364220 (has problem)


What is the status of VSYNC completely breaking, starting with 49.0.2587.0 (between r364188 and r364220)?

To confirm this new vsync problem, make sure to use a Windows computer with a confirmed vsync Hz *less* than 60Hz (for example, for my computer, the Hz is 59.802Hz).

See attached for what I see at www.vsynctester.com using these two versions.
r364220.jpg
34.8 KB View Download
r364188.jpg
36.8 KB View Download
No obvious changes between those two revisions. The only possibility I can see is https://chromium.googlesource.com/chromium/src/+/7c7ee3e822e34dd970ea38cb8db4b18da9ef61bb . Could you attach the about:gpu from Chrome both at r364188 and at r364220? 
jbauman/195: see attached
r364220.pdf
721 KB Download
r364188.pdf
1.1 MB Download
Cc: zmo@chromium.org
zmo@, do you know why https://chromium.googlesource.com/chromium/src/+/7c7ee3e822e34dd970ea38cb8db4b18da9ef61bb might prevent Chrome from using the GPU on an optimus system?

Comment 198 by zmo@chromium.org, Dec 17 2015

I don't think that CL does anything that caused the issue here.

Looking at the both about:gpu info, one thing is in 364220 we only recognize one GPU whereas in 364188 we recognize two?

Another possibility is we could lose GPU because of a cold run.  If you restart chrome again, the issue might just go away because we already cached the GL strings (using the same user-data-dir).
zmo/jbauman: Rerunning Chrome does not fix the problem.  Running with --ignore-gpu-blacklist causes Canary to properly VSYNC.  See attached for an about:gpu using this flag.

There must be some 'significant' change between r364188 and r364220 that is causing Canary to now ignore the GPU on my notebook, which is then causing 'no vsync' (and still not finding/reporting GPU1)?  Please fix under this issue (as no vsync), or if important enough, open a new issue...

r364220-ignore-gpu-blacklist.pdf
1.1 MB Download
zmo/jbauman: Just tested with the latest Canary 49.0.2595.0 (r365973) and the GPU is (mostly) back on (about:gpu attached; stangely canvas is not accellerated) -- but VSYNC is still not working, as per #192.
r365973.pdf
707 KB Download
zmo/jbauman: new very narrow bisect.  The new VSYNC problem #192 (GPU issue) on my notebook was introduced between r364188 (works) and r364195 (has problem).  Using "--ignore-gpu-blacklist" works around the problem.  This is really narrow now, and the change by 'zmo' seems the only possibility?  Can anyone else take a look and find the problem?

https://chromium.googlesource.com/chromium/src/+log/be041f3e7506d634d80f9bdb4323b118efd59554..c3e763a2164e421055b2a01d5b21426a9abca83a

The new problem discussed in #192-#201 has been moved into  issue 571241 .

Comment 203 by mit...@mithis.com, Dec 19 2015

Blockedon: chromium:571241

Comment 204 by zmo@chromium.org, Dec 21 2015

Something doesn't look right in #200 attached about:gpu

It says in the "Problems Detected" that video decode is software only, but in the Features, actually it says hardware accelerated.  Whereas the situation with canvas is the opposite.
zmo/204: yes, about:gpu is corrupted.  I will provide more details in  issue 571241 .

Comment 206 by mit...@mithis.com, Feb 24 2016

Cc: -mit...@mithis.com

Comment 207 by mit...@mithis.com, Feb 24 2016

Cc: tansell@chromium.org
Brian,

There is a new vsync problem in Chrome Canary, caused by canvas.drawImage().

I can not provide a bisect since  issue 571241  prevented me from testing vsync for several months.  Since  issue 571241  has just been fixed, I now notice major spikes (missed frames) in inter-frame timings on my notebook (see attached speed-20-pixel.jpg).

The new vsync problem must be caused by canvas.drawImage() (is this due to a change in how images are internally tiled or not?) since the spikes seen in inter-frame timings are directly correlated to the 'Background image' pixel scroll speed at www.vsynctester.com (and turning off drawing the background image, eliminates vsync spikes).  See the attached speed-1-pixel.jpg for when the drawImage() scroll speed is one pixel.

speed-20-pixels.jpg
26.4 KB View Download
speed-1-pixel.jpg
23.7 KB View Download
Owner: skyos...@chromium.org
Hi Jerry,

Brian is currently on paternity leave until end of April. I'm CCing skyostil as the current master of scheduling to triage. I'm guessing that we probably should have a new bug here too.
That canvas.drawImage() issue seems like it might be unrelated to the actual mechanics of requestAnimationFrame. Would you mind splitting that off into a new bug?

Is there something else left to be fixed here?
skyos/210: "Is there something else left to be fixed here?"  Yes, a lot.  Just some of the outstanding issues are:

There is a pretty glaring initialization problem in Chrome, where Chrome is not at all attempting to VSYC properly, until the Chrome application window is resized (under Windows).  I believe this is related to when Chrome uses Direct3D9Ex, which probably explains why no one there sees this issue?

Chrome is NOT syncing to VSYNC (yet).  On AC power, Chrome appears to be using spin waiting to wait until the correct sub 1-ms time.  On battery power, there is a very noticeable sawtooth pattern in callback timings, due to timer inaccuracy (on battery).  So Chrome+VSYNC+battery is not there yet.  Issue 467617 discloses how Chrome could fix this (and demo/source code was provided to briander..., bajones, sunn... and mit...).

Comment #208 problem still exists.

For me, VSYNC in Chrome/Canary since around Feb 2016 -- is once again broken.  Chrome can not pass the tests at www.vsynctester.com

enne, this change:

    f2d7f5e Turn on enable begin frame scheduling by default

has altered Chrome vsync accuracy behavior.  This appears OK and simply reverts Chrome back to a prior behavior, but this comment is to document side effects of your change.

Before the change (and turning off drawing the background image at vsynctester.com to avoid the comment #208 bug), Chrome was nearly perfectly vsync aligned -- but this accuracy was a false gain, as Chrome was spin-waiting for the correct sub 1-ms interval time (see attached before.jpg).  So spin waiting is good for vsync accuracy, but bad for power consumption.

After the 'enable begin frame scheduling' change, Chrome appears to now be back to its previous 1-ms accuracy (see attached after.jpg) behavior on A/C and 4-ms (approx) accuracy on battery (see attached ac2battery.jpg).

Chrome at some point needs to implement the VSYNC fix disclosed in issue 467617, which will trigger VSYNC in Chrome (on Windows) from the actual OS VSYNC trigger, instead of from (inaccurate) OS timers.  It is also important to note that this fix will be very power friendly as well (it does NOT require setting the global Windows timer accuracy lower, which increases power consumption).

I assume you also see these accuracy changes in your testing of Chrome/Windows?

before.jpg
32.7 KB View Download
after.jpg
49.3 KB View Download
ac2battery.jpg
67.6 KB View Download
skyos, Chrome fails this new VSYNC test (IE/Firefox pass the test just fine)...

Go to vsynctester.com, click on the gear icon, under 'Background image', click on 'Huge'.

The result is that the vsynctester.com performance graph appears great -- but the VSYNC indicator shows failure (color) on a periodic basis.

That means that Chrome is rendering frames just fine, but is unable to place those rendered frames in unique display frames.

Is there a reason that none of my recent comments (211/212/213) are being responded to?  It makes it look like this bug/issue is dead (no longer being work on).

Will resources be assigned to fix VSYNC, or not?  Been waiting since Oct 9, 2014.

Firefox beats the pants off of Chrome right now.  See the attached for vsynctester.com snapshots of Firefox vs Canary.

The amount of variation in requestAnimationFrame() callback times (vsync scheduling) on battery (Windows) is a problem, with a known easy fix (that is not being implemented).

firefox-on-battery-GOOD.jpg
37.3 KB View Download
canary-on-battery-BAD.jpg
70.9 KB View Download
Owner: ----
Status: Available (was: Started)
BeginFrame scheduling goes a long way of bringing some sanity to Chrome's vsync architecture, and is being actively worked on. D3DKMTWaitForVerticalBlankEvent() is an obvious subsequent improvement, but we need to get the basics in first.

I still think #208 should be split off into its own bug since centithreads like this are very hard to follow.

(By the way, I somewhat disagree that we should be aiming to run rAF at exact wall clock intervals. As long as we hit the deadline for the next frame and provide a consistent timestamp parameter to rAF, the user will see a perfectly smooth animation. This gives the browser and the OS some leeway for scheduling things more efficiently.)

(Marking available since I'm not personally working on any aspect of this at the moment.)
skyos/215,

> By the way, I somewhat disagree that we should be aiming to run rAF at
> exact wall clock intervals. As long as we hit the deadline for the next
> frame and provide a consistent timestamp parameter to rAF, the user will
> see a perfectly smooth animation. This gives the browser and the OS some
> leeway for scheduling things more efficiently.

What about input, like mouse and touch input, that many animations (games) depends upon?  And how that input interacts with a vsync callback that is varied instead of constant?

If the input delay (time from input until a frame is displayed that acts on that input) is not constant, but varies, that is a noticeable (visible) problem.

#208 is now new  issue 631166 , and with a bisect (with a 'cache purge' the suspect?).
Thanks for filing and bisecting the new bug!

I agree that input definitely needs to be delivered "in sync" with requestAnimationFrame, and that's indeed things work on Android and very soon on other platforms too. Like rAF, input events also come with timestamps, so it is possible to render a smooth input response despite some small OS scheduling noise.
Chrome fails vsynctester.com with Intel HD graphics 3000/4400/5500.  Will others report their results?
When briander... was the owner of this issue, we tried to keep all VSYNC related bugs in this issue.  That has recently changed.  Could we mark this issue as being BLOCKED on these issues:

1.  issue 632785  - proper VSYNC is broken (Windows) until Chrome app window is resized

2.  issue 631166  - too aggressive GPU cache purge is causing missed frames (VSYNC spikes)

3. issue 467617 - how to dramatically improve Chrome's requestAnimationFrame VSYNC accuracy in Windows

4. issue 465105 - an issue tightly related (Chrome internals) to missed frames (VSYNC issues)

5. issue 464835 - Chrome's 96MB GPU limit is unnecessarily causing missed frames (VSYNC issue).  Fixed by turning off the GPU for canvas!

6.  issue 367355  - Chrome's 96MB GPU limit is unnecessarily causing missed frames (VSYNC issue).  Fixed by turning off the GPU for canvas!

It would help us all track all of the issues that are causing VSYNC problems.

Also, can we get a new owner assigned to this issue ASAP?

Chrome is now failing vsynctester.com for me under Windows no matter what GPU is being used (Intel/Nvidia/etc).  Even on a top of the line Nvidia GPU with 10GB video memory.  Turning OFF the GPU for canvas causes Chrome to once again pass vsynctester.com!

Thanks.

Blockedon: 467617 631166 632785 465105 464835 367355
Components: Internals>GPU
Summary: Chrome fails some vsynctester.com tests (was: Chrome 38 busts "vsync" and causes jerky <canvas> requestAnimationFrame() animations)
Another mildly annoyed Chrome user starring this issue.


Labels: -Type-Bug-Regression Type-Bug
This is causing me all sorts of headaches, all of which are compounded by the growing relevance of 4K displays. The ridiculously low hardcoded 96mb gpu cache limit gets eaten up in no time.

Astonishingly, general usage of Microsoft Edge is now noticeably smoother and far more pleasing.
We've seen this issue happen to www.testufo.com

We have a similar VSYNC tester at http://www.testufo.com/#test=animation-time-graph though the vsynctester.com is a far more advanced tool that can dive more into low-level subtleties.

Please fix.
I have been battling with this particularly on two 4K displays, two computers i5 and i7, 3 graphics cards the latest was GTX-1060 6Mb.
I have just noticed something that might help...
When the mouse is not over the Browser window everything improves. (with hardware acceleration OFF).
However as soon as I move the focus from another window back to the browser window the tearing/jerky behavior starts up again.  I've turned off smooth scrolling which some people say has worked for them.  
Poor display - Mouse IS over browser.JPG
436 KB View Download
OK display Mouse not over browser.JPG
523 KB View Download
... so I'm now thinking...
How do I watch a movie in full 4K and keep the mouse pointer 'out of view'?
We are getting similar issues after noticing problems for our newest game after chrome failed to produce adequate results for our game IronVice at ironvice.com. We are now considering abandoning the browser entirely.
I am also seeing this error.
#228: Would you mind filing a new bug with details on how to reproduce the issue on ironvice.com? I just want to make sure we're not conflating issues here.
I updated to the latest version of Chrome and found the 44.0 MP benchmark on vsynctester.com to run fine. Can anybody confirm?
With canary at least some of the vsync issues still exist with my intel 5000 integrated graphics. Issues are exacerbated with a second monitor. We have encountered many issues with iron Vice + Chrome. The browser/our users are not ready for that level of 3D to run smoothly on most people's setups (~80+%). I meant to comment on this specific bug effecting IronVice as well. Thanks for the quick response skyos
What's changed?   
The problem seems to be fixed when testing with vsync.com !
I have Chrome 54.0.2840.99 m
Firefox 50.0.2 seems to be good too.
Issues are the same for me.

Comment 235 Deleted

It looks (from #231 and #233) that at least part of this bug is no longer reproducible. Is this still an open issue and can someone please state exactly what the remaining issues are and what the current status is? Note that this is currently the #4 most starred Blink bug.
I've attached a screenshot of the vsync still having issues with chrome canary. Let me know if you need anymore debugging help. The vsync seems to be mostly ok but has it's ups and downs based on some imperceivable change elsewhere. The vsync errors don't seem to have anything to with the application itself. 
Screen Shot 2017-01-23 at 2.53.53 PM.png
955 KB View Download
Screen Shot 2017-01-23 at 2.55.31 PM.png
64.1 KB View Download
This bug appears to be cured - for me at least.

Comment 233
<https://bugs.chromium.org/p/chromium/issues/detail?id=422000#c233> by
sandy.mc...@gmail.com <https://bugs.chromium.org/u/2151606619/>, Dec 7

What's changed?
The problem *seems to be fixed* when testing with vsync.com !
I have Chrome 54.0.2840.99 m
Firefox 50.0.2 seems to be good too.
I notice that when a FB notification came in you can see on the upper right the graph on the left most side shows a large VSYNC issue. Also on a second monitor the graph is consistently flawed. I can provide a graph for that too if necessary.
Screen Shot 2017-01-23 at 3.15.53 PM.png
588 KB View Download

Comment 240 by rea...@gmail.com, Jan 25 2017

It's broken on my 120Hz monitor. I tried all of these:

55.0.2883.87
56.0.2924.67
57.0.2986.0

And they all sync to 55-57FPS (it constantly "jitters" between values.) Not only on the vsynctester site, but on every site. Including youtube. The result is that all videos stutter, and so does scrolling.

In short, Chrome is broken on Linux when using a low-blur/high-refresh monitor.

Comment 241 Deleted

Cc: -tansell@chromium.org
Re: Comment 240

rea...@gmail.com I have my doubts that it is Chrome's fault that you never reach 120fps. Perhaps one of your processors is too weak. Therefore knowing CPU, GPU, and mainboard model may help. 

Can you check if enabling/disabling hardware acceleration in your Chrome settings makes a difference?

Comment 244 Deleted

Comment 245 by a...@scirra.com, Feb 20 2017

Android v-sync accuracy appears to have regressed recently. rAF-driven canvas animations now only run at 50 FPS and look janky. Please see  issue 694267 
Please consider marking this issue blocking on new  issue 694267  (Android vsync regression), and possibly on new issue 694075 (how automated test could detect vsync regressions).
Cc: stanisc@chromium.org

Comment 248 Deleted

Cc: -simonh...@chromium.org junov@chromium.org
Components: Blink>Canvas
Labels: -Needs-Feedback
Adding the canvas label and some folks from the canvas team since this seems to be canvas related.

@Junov so you don't have to re-read the thread:
It looks like Chrome might be dropping frames on vsynctester.com periodically. I can get the 'VSYNC' text to flash cyan or blue relatively reliably by quickly dragging my cursor back and forth across the links at the bottom of the page.

http://www.vsynctester.com/chromeisbroken.html has a fairly detailed description of what the problem might be.

Could you take a look and see if you can repro?

Comment 250 Deleted

Comment 251 Deleted

Running full screen canvas, jankiness is far less likely to happen than when mixing HTML and canvas.  The canvas element can skip when HTML is updates.  It also happens at testufo.com when it tries to update the statusbar at bottom.

If you go to www.testufo.com/animation-time-graph and start moving mouse all over the place, you can see fluidity variances as the processing overhead of different page elements (canvas and non-canvas) compete against each other.  Mouseover the hyperlinks, mouseover the tabs, click the pulldown listboxes, and watch what happens to the animation timing -- and how it suddenly stutters at that time.  

Presumably, processing priority is rightfully given to user actions, like mouse control, and this can naturally cause outside-canvas user activity to cause CPU cycles to move away from canvas processing and/or compositing.  Especially if either is done via a slow path (software).

On a related note -- for VSYNC related topics I am now an Invited Expert in W3C Web Platform Working Group, specifically working on a VSYNC API, I'd like your help with W3C HTML Standards discussion on a VSYNC API  -- https://github.com/w3c/html/issues/375 --

This item in W3C's tracking system discusses an improved future VSYNC API (plus variable refresh rate support, plus VSYNC OFF support, aka Javascript access to Chrome's --disable-gpu-vsync command line option)
Owner: junov@chromium.org
Assigning to someone from the canvas team to take a look. @Junov - we're trying to get a concrete next action (along with a NextAction date) for the top 1% of starred bugs. 

Could you take a look at this bug and identify what the next step to resolve it would be, along with when we might be able to make that progress?
Please remove me from this thread I am sick of getting emails for it and
cannot figure out how to do it myself thanks
Cc: ericrk@chromium.org
@#253: There is concrete work in progress for resolving this issue
ericrk@ is working on a GPU memory management framework that will help drawImage performance by allowing us to remove the GPU texture cache limit.
stanisc@ is working on a VSYNC infrastructure to improve the synchronization of animations the the display hardware.
I have screen tearing with Google Chrome. But small and only at top of screen.

One line.


36Ovygh[1].png
192 KB View Download
FLATRON W1934S (59hz?)
GeForce 9500GT
AMD 5000+ x64 Dual Core
4GB RAM
WIN7 x64
Guys, please dont take offence, I know this is a tricky one, but 4 years!  ?

Web games (which are supposed to be the future of gaming) or anything requiring smooth movement still look like absolute crud on chrome with all the stuttering and janking.

Shouldn't this be priority one ?


pls :(
It'd be great to advance the fix of this bug, or hear any news about it.
To the next 4 years boys!

Bug is still not fully fixed #enable-d3d-vsync helps but it's not fully fixed.


Cc: -junov@chromium.org
Owner: ----
Blockedon: 891656 891653
I took a look at the latest state of things here -- let me try to summarize and please let me know if I missed something:

1. VSync accuracy at M71 on Linux seems to be fairly good according to the test. I believe this is largely due to the new Viz display compositor which moves compositing work outside the browser process. It's still in the process of being rolled out, but if you want to try it sooner you can use the --enable-features=VizDisplayCompositor command line flag.

2. There's an upcoming redesign to the BeginFrame pipeline which will help eliminate some of the IPC delays that are causing jank here, but it's still very much in the works.

3. Some specific issues still remain -- see the list of blocking bugs including some new ones I've added. Some of these are platform-specific (D3D) while others require some architectural work to fix (high latency mode)

If you're having issues with Chrome's rendering that aren't specifically about the scheduling of requestAnimationFrame callbacks (such as screen tearing), please file a new bug to keep this one a bit more focused.
Project Member

Comment 265 by bugdroid1@chromium.org, Oct 22

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1cf0735972f3ef700e4ded41b124b565a5cea560

commit 1cf0735972f3ef700e4ded41b124b565a5cea560
Author: Sami Kyostila <skyostil@chromium.org>
Date: Mon Oct 22 12:16:25 2018

Increase timer resolution

Now that site isolation is enabled on desktop platforms, we can safely
increase timer resolution back to the previous 5µs value. Clock edge
jittering is still enabled however.

Bug: 798795, 422000
Change-Id: I23f29a40a8615354674f33bae7339d348773dd00
Reviewed-on: https://chromium-review.googlesource.com/c/1290916
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601536}
[modify] https://crrev.com/1cf0735972f3ef700e4ded41b124b565a5cea560/gin/v8_platform.cc
[modify] https://crrev.com/1cf0735972f3ef700e4ded41b124b565a5cea560/third_party/blink/renderer/core/timing/time_clamper.h

Showing comments 166 - 265 of 265 Older

Sign in to add a comment