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

Issue 262437 link

Starred by 12 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Oct 2013
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Lag in some flash games since version 30 (Windows 8)

Reported by, Jul 20 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1568.2 Safari/537.36

Steps to reproduce the problem:
Games that I've noticed reduced performance.
Candy Crush

What is the expected behavior?
Normally very smooth 60fps.

What went wrong?
Games are very laggy.

Did this work before? Yes Version 29

Chrome version: 30.0.1568.2  Channel: dev
OS Version: 6.2 (Windows 8)
Flash Version: Shockwave Flash 11.8 r800
Showing comments 13 - 112 of 112 Older
I'm able to confirm the issue on Windows 7.

With all of the Three.js examples, Chrome stable (v28) runs them at 60 FPS and Chrome Canary (v30) runs them at 30 FPS.

The issue isn't reproducible in OSX 10.8.4.

868 KB View Download

Comment 14 Deleted

It appears that just calling requestAnimationFrame() still results in 60 FPS. But if you create a context, and use that context to draw to a canvas it drops down to 30 FPS in Chrome (v30) on Windows.

Attached is source code that runs at 60 FPS on Chrome Stable (v28) and 30 FPS on Chrome Canary (v30) in Windows.
820 bytes View Download
Labels: -Cr-Internals-Plugins-Flash Cr-Internals-GPU
I have tried to test couple of urls mentioned above and have noticed that the fps rates are ~60 in M29 builds and in M30, I noticed that the fps rates were ~30-40 in 30.0.1573.2. Which was a problem. But with the latest build 30.0.1574.1 (Canary), the fps rates are again back to ~60. The performance is now consistent on the latest canary on almost all the urls mentioned above in Windows 8.

So, please test the same in the latest canary version mentioned above and let us know if you still see the problem.

I am hoping that the gpu performance issue is resolved in the latest build as mentioned above.

Comment 17 by, Jul 27 2013

Chrome canary version 30.0.1578.3 on Windows 8 Pro 64bit still gives me 30fps on from my post above.

Chrome version 28.0.1500.72 m gives 60fps.


Comment 18 Deleted

Labels: -Type-Bug -Needs-Feedback Type-Bug-Regression M-30
Status: Untriaged
Able to reproduce the issue on Win8. Navigated to the URL and observed that it gives 60fps in M29 and 30 fps in M30

This is a regression in M30 and below is the bisect info
Manual Bisect:
Good Build : 30.0.1554.0 
Bad Build : 30.0.1557.0
You are probably looking for a change made after 210100 (known good), but no later than 210122 (first known bad).
Labels: -Pri-2 Pri-1 ReleaseBlock-Stable
Status: Assigned
Looks like r210106 is the culprit  ,@danakj ,could u pls take a look
That CL introduced a large memory leak every time a readback was performed. This was later fixed in r213297.

Does this still reproduce past that revision?
Tested the same on win8 chrome version 30.0.1581.2 (Official Build 214301) and issue is still reproducible - runs at ~30fps.
Did you bisect to my CL or just to the above range? That CL changes the aura thumbnailer code, and I have a hard time believing that we are running thumbnailer constantly. A memory leak causes memory thrashing, so I could see that being related, but otherwise it doesn't seem like it.
Labels: Needs-Feedback
This bug is in dev channel. Do we use WinAura in dev channel? I thought that was only in Canary channel. My CL only affects aura, so it sounds like this is another CL at fault to me?
Labels: Needs-Bisect
Owner: ----
Status: Untriaged
Reply to comment #24 : We do not use Aura for Dev channel . May be we need to bisect aging to find the correct CL. Sorry for the confusion


Comment 27 by, Jul 31 2013

Maybe r210101. terryhau or someone else who's able to reproduce the problem, can you copy and paste the contents of chrome://gpu here?
Labels: -Needs-Feedback -Needs-Bisect
I am able to reproduce this issue in - current dev 30.0.1581.2 , Win 7 and did a re-bisect and its same as mentioned in comment #19.

Attaching chrome://gpu details.

Note : This issue is specific to windows , renders @60 fps in mac & linux
4.9 KB View Download
Still seeing issue on latest dev channel version 30.0.1581.2.

4.9 KB View Download

Comment 31 by, Aug 1 2013

Status: Assigned
brian could it be ?

there's no blink roll, or gpu changes, or v8 roll in the range.

I'll take a look.

The suspected patch is used on all platforms, so it's strange that it is only affecting Windows.  It's possible that Windows is setting the timebase and interval in a way that tickles it funny though.

Comment 33 by, Aug 13 2013

Latest dev channel 30.0.1599.0 still has the issue.

Comment 34 by, Aug 13 2013

brian are you looking at this?
Sorry, I dropped the ball on this. It took me a while to get my Windows machine compiling again, but it's working now.

I'm on this 100% now.
I can not reproduce locally. @terryhau or @ligimole, can you upload a trace recorded with chrome://tracing ?

Comment 37 Deleted

Comment 38 by, Aug 14 2013

Here is a trace.
3.5 MB Download
Looking at the trace, this is almost certainly related to The frame ticks are mostly 32ms apart, with a only a handful at 16ms apart. For the 32ms frames, there is no check and skip in the middle, the DelayBasedTimeSource just posts a task too far into the future.

That patch can be reverted without any major side effects. Its main purpose was to reduce trybot flakiness, but I made some other changes to have the frame timestamp reflect when it was supposed to be scheduled rather than when it was actually scheduled.

I would still like to figure out what is going on though. This code is common to all platforms, but only seems to fail on Windows with specific device configurations.
I have a fix for this in progress.

Although I still haven't been able to reproduce this bug locally, I do have a unit test I was able to create that causes us to post frames too far into the future. I am pretty sure they have the same root cause.

In the trace @terryhau uploaded, I noticed the timebase in OnVsyncParametersChanged increments by much more than a vsync each frame. This is a bug of it's own. @apatrick, do you know what might be going on here? Is there an existing bug for this?

That, in turn, hit a bug in my code on line 195 of

If the timebase is sometime in the future, the result of that line would be negative which, according to C99 truncation rules, would round up towards 0 instead of rounding down towards 0.  That rounding up instead of down eventually adds an extra vsync to the delay.
It seems everyone who can reproduce this and has provided the about:gpu contents is using a monitor with a refresh rate of 59Hz. 60Hz is the more common frequency. Is it possible there is some code that thinks if a frame doesn't fit in 1/60th sec it has to skip a frame? Just a wild guess.
I have a fix up for the DelayBasedTimesource bug here:

@apatrick, I looked into the 59Hz clue and it doesn't affect any of the DelayBasedTimeSource unit tests.  Could it affect the vsync timebase estimation logic on Windows?
@briananderson, I found a machine that can do both 60Hz and 59Hz and switched between them and 59 did not make the frame rate drop for WebGL aquarium and a few other pages listed here. Probably a red herring.

Comment 44 Deleted

Comment 45 by, Aug 15 2013
This is the reason why most people are on 59hz (actually 59.94) and not 60hz.

Certain monitors report a TV-compatibility timing of 59.94Hz. Therefore, Windows 7 exposes two frequencies, 59Hz and 60Hz, for every resolution that is supported at that timing. When a user selects 60Hz, the OS stores a value of 59.94Hz. However, 59Hz is shown in the Screen refresh rate in Control Panel, even though the user selected 60Hz. Both 59Hz and 60Hz are translated to 59.94Hz before these values are sent to the driver. Therefore, the display is identical at 59Hz and 60Hz.
Project Member

Comment 46 by, Aug 15 2013

r217723 | | 2013-08-15T01:22:04.027351Z

Changed paths:

cc: Handle future timebases properly in DelayBasedTimeSource

The existing code didn't anticipate negative values for
intervals_elapsed, which would round up towards 0 instead
of down towards 0 and cause the next frame to be posted
more than 1 vsync away.

This primarly cropped up on Windows machines, but only
for certain configurations.

BUG= 262437 

Review URL:
Labels: Merge-Requested

Comment 48 by, Aug 15 2013

let's let this go to canary :)

Comment 49 by, Aug 15 2013

how's it looking?

Comment 50 by, Aug 15 2013

how's it looking?
It doesn't look like my patch made it into Canary yet.

Does Canary still have WinAura enabled? If so, the bug may not reproduce there and we won't be able to tell if the bug has been fixed in Canary. We will at least be able to tell if anything blows up.

If nothing blows up in Canary, can I merge into Dev to have folks who can reproduce the bug verify the fix?

Comment 52 by, Aug 16 2013

ping? i am just a bit nervous about patching this in... 
The patch has made it to Canary. Canary is still using WinAura, but the patch is working well.

I think it is ready to merge into the Dev branch. Once the patch hits the Dev branch, hopefully someone that can reproduce this bug can verify that we're back at 60fps.

Comment 54 by, Aug 16 2013

problem is canary wil continue to be aura. so how can i be sure this is ok? we don't just merge things to branch for testing to see... is this win8 only? if so, can we limit the code to be win8 only?

Comment 55 Deleted

@tkonchada, are you still able to reproduce this bug on the Dev channel? If so, can you verify that Canary .0 (non-WinAura) builds do not reproduce?
Not able to reproduce the issue on latest dev 31.0.1605.0 in win7 and win8.

It displays  ~60 fps in latest dev channel.

Comment 59 by, Aug 19 2013

do u mean dev or canary? dev is still M30.
Issue is reproducible in win8 chrome version 30.0.1599.15 (Official Build 218581) m - Displays between 29 and 32 fps.

Working fine in win7 30.0.1599.15 (Official Build 218581) m - runs smooth with ~60 fps.

Working fine in win7, win8 chrome version 31.0.1605.0 - runs smooth with ~60 fps.

Comment 61 by, Aug 21 2013

but we didn't merge...
I think @tkonchada's results in #60 indicate that the patch is working in Canary, even though the Dev branch is still failing for her.

I translated the results as follows:

> Issue is reproducible in win8 chrome version 30.0.1599.15 (Official Build 218581) m - Displays between 29 and 32 fps.

Dev branch, without the patch in #46, fails on win8.

> Working fine in win7 30.0.1599.15 (Official Build 218581) m - runs smooth with ~60 fps.

Dev branch, without the patch in #46, works on win7.

> Working fine in win7, win8 chrome version 31.0.1605.0 - runs smooth with ~60 fps.

Canary branch (without WinAura), with the fix in #46, works on win7 and win8!

Comment 63 by, Aug 22 2013

oic! win8only sorry, brain freeze. okie we're gonna hold off on this one and see how many people are affected before we make a move.

Comment 64 by, Aug 28 2013

Dev channel updated to 31.0.1612.1 dev-m Aura today for me.
The issue is fixed on this version.

Comment 65 by, Sep 5 2013

the plan is still not to merge this. i believe.
Labels: TE-Verified-M31 TE-Verified-31.0.1623.0
Tested the issue on Windows 8 OS - chrome version 31.0.1623.0 (Official Build 221536). Fix is working as intended.
49.5 KB View Download
Note: If we do decide to merge, @enne has fixed another issue with the DelayBasedTimeSource logic in and we should merge that patch in as well.

Comment 68 by, Sep 11 2013

but i thought the agreement was that we merge neither right?
Correct, we are not merging either patch. I just wanted to add info that we shouldn't forget, just in case the decision changes.

Comment 70 by, Sep 11 2013

Could someone please explain for the non-developers, what needs to happen before this can be merged.

Comment 71 by, Sep 13 2013

unfortunately this patch is a bit too risky for M30, so it will wait for M31. 
Labels: Needs-Feedback
Owner: ----
@Kareng: Could you please confirm whether it is merged to M30? So, that QA can verify on M30 else will wait.

Comment 73 by, Sep 25 2013

not merged. we're not going to merge this unless we need to. 

Comment 74 by, Sep 25 2013

brian i'll amke u owner since u'll have to merge this if we take it.
Labels: -Needs-Feedback
The stutters are also occuring with HTML5 animations, including at places like and elsewhere.

I am also getting this problem with the Motion Tests at too, as well in Chrome 30.0.1599.66  .... This motion test used to work perfectly in Chrome, but not with this version.

Chrome used to be one of the best browsers for animations:
But 30.0.1599.66 has squarely placed Chrome worse than IE, FF, Opera, and Safari.

A good test include:
This reveals animation timing variances.
This graph now looks very ugly in Chrome 30.0.1599.66 unlike previous releases.

Comment 77 by, Oct 2 2013

I can't reproduce significant timing variances with running 30.0.1599.66 (Official Build 225456) on Mac OS X 10.8.5. Tested on both a desktop Mac with an AMD Radeon HD 7950 (not a common graphics card, admittedly) and a MacBook Pro Retina Display.

Comment 78 by, Oct 2 2013

Screen shot showing timing from the above test.

Screen Shot 2013-10-02 at 1.27.00 PM.png
98.3 KB View Download
If this is the same thing as then we really need a fix into M30 ASAP.
KBR, I believe it's a bug affecting Windows platforms, rather than Mac.
It is apparently affecting everything, making Windows Chrome 30 the worst browser in fludiity:

Common use case:
-- (WebGL beta) -- Much slower and worse in Chrome 30
Panning Google Maps is much jerkier...

Futuristic use case:
-- Unreal HTML5 demo at 
("Try Anyway" performed fast/well in Chrome 29 on a Geforce GTX680, now framerate is less than half in Chrome 30!)

Comment 82 Deleted

KBR, that looks like what Chrome 29 does on Windows (beautifully flat).
Here's a screenshot of what it looks right now in TestUFO in Chrome 30 on Windows:
105 KB View Download
Looks like DelayBasedTimeSource is using base::TimeTicks::Now, while vsync timebase is made using base::TimeTicks::HighResNow. Those times have different bases on windows.

Comment 85 by, Oct 2 2013

I see. I don't have a Windows 8 machine to test on but can't reproduce the issue on Windows 7 either.

Comparison of other web browsers (this clearly shows Chrome 30 Windows is abnormal)

123 KB View Download
@karen - we need either to merge the fix or revert the broken patch and push ASAP, the current state is not acceptable.  This is really really bad.  Assigning to you to set the Merge-? bit appropriately.
Yes, I'm using Windows 8 too as well.   
Even the sliding page-transition animations at is jumpy/jerky/juddery now; I'm noticing it in almost every website I visit now.
 Issue 302883  has been merged into this issue.

Comment 90 by, Oct 2 2013

ok so we want to revert the original CL brian landed? can someone check if it reverts cleanly from 1599. if we need this asap, we will have to merge to 1599_59 cause I am using that branch for now.
Yeah, just checked, and seems like it reverts cleanly (
P.S. While we're working on this, I should politely point out  Issue 158234  has not yet been fixed for more than a year; while both FireFox and IE has already fixed it, as evidenced by the comparison screenshot at "image-graph-of-performance-now-IEvsFFvsCHROME.png".  

This hurts precision animation debugging in Chrome, as is one of the world's highest animation-precision website (complete with HTML5 heuristics to detect your computer's refresh rate, with 95-99% accuracy).
Can folks who are seeing this tell us what sort of hardware you're on?  I.e. laptop vs desktop, model, age, and if you're plugged into an external monitor?
CPU: Intel Core 2 Q6600 (7 years)
GPU: nVidia GTX 460 (3 years)
Windows 8
Project Member

Comment 95 by, Oct 2 2013

Labels: merge-merged-1599
r226615 | | 2013-10-02T23:30:08.107081Z

Changed paths:

Revert 210101 "cc: Fix and simplify DelayBasedTimeSource"

> cc: Fix and simplify DelayBasedTimeSource
> - This converts some floating point math to integer math
> to avoid rounding errors.
> - Assigns last_tick_time_ to be the time it was *supposed*
> to tick and no longer uses it as a synonym for "now".
> - Adds trace events to help debug when the interval or
> phase changes.
> BUG= 256650 
> Review URL:
BUG= 262437 

Review URL:
Project Member

Comment 96 by, Oct 2 2013

Labels: merge-merged-1599_59
r226617 | | 2013-10-02T23:33:00.230781Z

Changed paths:

Revert 210101 "cc: Fix and simplify DelayBasedTimeSource"

> cc: Fix and simplify DelayBasedTimeSource
> - This converts some floating point math to integer math
> to avoid rounding errors.
> - Assigns last_tick_time_ to be the time it was *supposed*
> to tick and no longer uses it as a synonym for "now".
> - Adds trace events to help debug when the interval or
> phase changes.
> BUG= 256650 
> Review URL:
BUG= 262437 

Review URL:
@terryhau - thank you!  Do you know the model of your display?  Is there just one plugged into the desktop or multiple?

CPU: Intel Core 2 Q6600 (7 years)
GPU: nVidia GTX 460 (3 years)
Monitor (single): Dell 2407wfp-hc (6 years)
Windows 8

Comment 99 by, Oct 2 2013

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
I can repro locally (my displays report 59Hz), building before/after 210101 to confirm.
I confirm that 210100 is relatively smooth on and 210101 is jittery.

dxdiag reports a 59Hz monitor, LMK if there's somewhere easy to confirm that in Chrome if you want it.
"Relatively" smooth? -- I hope you just mean the graph itself

Animations should look 'perfect synchronized to refresh' like it was in Chrome 29 during a green 'VALID' at TestUFO.  Generally, anything that jitters less than half a refresh length (graph has no spikes more than ~8ms at 60Hz) will still synchronize perfectly smooth animations in Chrome.

Visual verification check:

Yes, the graph.

Comment 105 by Deleted ...@, Oct 3 2013

I switched from Firefox to Chrome just recently because would not stay at 60fps on Firefox. It was buttery smooth 60fps all the time on Chrome until today. Everything on chrome is capped at 30fps(Frames per second) and is very sad.
@scottmg was kind enough to run ToT without WinAura and verified that the issue does not reproduce there. This is the first confirmation we have that the patches in #46 and #67 actually fix the original issue. We had trouble verifying the fixes at first because the issue did not reproduce with WinAura and so we couldn't verify the patches first by rolling out to users through Canary, which left us in a tough spot.

Even though it looks like the fixes are working, it's still safest to just revert the patch in M30 this late in the game. Thanks @jbauman for getting that up so quickly. I double checked and there aren't any scheduling changes in M30 that depend on that patch. The reverted version of the DelayBasedTimeSource has been in many releases and should be safe.

Comment 107 Deleted

For people who can't wait for Chrome stable to fix this...
People who are reading this, Beta 31.0.1650.8 beta-m has just come out.

It also fixes this problem.  
To the relief of people at 
Good job everyone.  
That's quite a fast release to stable. 30.0.1566.69 fixes the problem.

That said, Chrome 30 does not seem to work as smooth as Opera 15+. Why?
Look at how Opera can spend 80% CPU inside rAF() and still be perfectly smooth.
Why is this the case, since Opera now uses the Chrome engine?

The Excel spreadsheet was done by using the easteregg option:
This allows you to insert a busywait loop inside requestAnimationFrame().
My above post is lower priority, might need to be split out into a separate issue (as this is unrelated to this sudden version-to-version performance loss)
Status: Fixed
closing this one for m30.
I have created a new  Issue 304367  to cover the other longstanding requestAnimationFrame() fluidity issue of Chrome on Windows platforms.

Note: This is referring to the Windows version of Chrome.  
The Mac version of Chrome does not have this problem.

i7 on Desktop PC with Geforce GTX 680 ... stuttery.
i7 on Macbook Pro Retina with Geforce GT650M ... smooth.
Showing comments 13 - 112 of 112 Older

Sign in to add a comment