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
Owner:
Email to this user bounced
Closed: Oct 2013
Cc:
Components:
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 terry...@gmail.com, 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
live.chess.com

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.


ChromeCanary_FPSIssue.png
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.
chrome_v30_fps_issue.html
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 crow...@gmail.com, Jul 27 2013

Chrome canary version 30.0.1578.3 on Windows 8 Pro 64bit still gives me 30fps on http://lazyslug.dyndns-ip.com/lifeview/ from my post above.

Chrome version 28.0.1500.72 m gives 60fps.

Chris

Comment 18 Deleted

Cc: tkonch...@chromium.org ligim...@chromium.org
Labels: -Type-Bug -Needs-Feedback Type-Bug-Regression M-30
Status: Untriaged
Able to reproduce the issue on Win8. Navigated to the URL http://lazyslug.dyndns-ip.com/lifeview/ 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).
CHANGELOG URL:
  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/tru
nk/src&range=210100%3A210122
Labels: -Pri-2 Pri-1 ReleaseBlock-Stable
Owner: danakj@chromium.org
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.
Cc: -ligim...@chromium.org danakj@chromium.org
Labels: Needs-Feedback
Owner: ligim...@chromium.org
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?
Cc: ligim...@chromium.org
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

Cc: -danakj@chromium.org

Comment 27 by kareng@google.com, Jul 31 2013

Cc: apatrick@chromium.org jbau...@chromium.org
Cc: briander...@chromium.org
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
gpu.txt
4.9 KB View Download
Still seeing issue on latest dev channel version 30.0.1581.2.

gpu.txt
4.9 KB View Download

Comment 31 by kareng@google.com, Aug 1 2013

Owner: briander...@chromium.org
Status: Assigned
brian could it be http://src.chromium.org/viewvc/chrome?view=rev&revision=210101 ?

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 terry...@gmail.com, Aug 13 2013

Latest dev channel 30.0.1599.0 still has the issue.

Comment 34 by kareng@google.com, 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 terry...@gmail.com, Aug 14 2013

Here is a trace.
trace.zip
3.5 MB Download
Looking at the trace, this is almost certainly related to http://src.chromium.org/viewvc/chrome?view=rev&revision=210101. 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.
Cc: kbr@chromium.org
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 http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/delay_based_time_source.cc?pathrev=210101

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: https://codereview.chromium.org/22887010/

@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 terry...@gmail.com, Aug 15 2013

http://support.microsoft.com/kb/2006076
This is the reason why most people are on 59hz (actually 59.94) and not 60hz.

tldr
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 bugdroid1@chromium.org, Aug 15 2013

------------------------------------------------------------------------
r217723 | brianderson@chromium.org | 2013-08-15T01:22:04.027351Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/delay_based_time_source_unittest.cc?r1=217723&r2=217722&pathrev=217723
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/delay_based_time_source.cc?r1=217723&r2=217722&pathrev=217723

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: https://chromiumcodereview.appspot.com/22887010
------------------------------------------------------------------------
Labels: Merge-Requested

Comment 48 by kareng@google.com, Aug 15 2013

let's let this go to canary :)

Comment 49 by kareng@google.com, Aug 15 2013

how's it looking?

Comment 50 by kareng@google.com, 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 kareng@google.com, 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 kareng@google.com, 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?
Owner: tkonch...@chromium.org
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 kareng@google.com, 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 kareng@google.com, 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 kareng@google.com, 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 terry...@gmail.com, 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 kareng@google.com, 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.
Screenshot.png
49.5 KB View Download
Cc: enne@chromium.org
Note: If we do decide to merge, @enne has fixed another issue with the DelayBasedTimeSource logic in https://chromiumcodereview.appspot.com/23839003 and we should merge that patch in as well.


Comment 68 by kareng@google.com, 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 terry...@gmail.com, Sep 11 2013

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

Comment 71 by kareng@google.com, Sep 13 2013

unfortunately this patch is a bit too risky for M30, so it will wait for M31. 
Cc: rponnada@chromium.org
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 kareng@google.com, Sep 25 2013

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

Comment 74 by kareng@google.com, Sep 25 2013

Owner: briander...@chromium.org
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 apple.com and elsewhere.

I am also getting this problem with the Motion Tests at http://www.testufo.com 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:
http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/
But 30.0.1599.66 has squarely placed Chrome worse than IE, FF, Opera, and Safari.

A good test include:
http://www.testufo.com/#test=animation-time-graph
This reveals animation timing variances.
This graph now looks very ugly in Chrome 30.0.1599.66 unlike previous releases.

Comment 77 by kbr@chromium.org, Oct 2 2013

I can't reproduce significant timing variances with http://www.testufo.com/#test=animation-time-graph 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 kbr@chromium.org, 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 https://code.google.com/p/chromium/issues/detail?id=302883 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:
-- http://maps.google.com (WebGL beta) -- Much slower and worse in Chrome 30
Panning Google Maps is much jerkier...

Futuristic use case:
-- Unreal HTML5 demo at http://www.unrealengine.com/html5 
("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:
Poor_Chrome30_fluidity.png
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 kbr@chromium.org, 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)

image-graph-of-performance-now-IEvsFFvsCHROME.png
123 KB View Download
Owner: karen@chromium.org
@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 http://www.apple.com is jumpy/jerky/juddery now; I'm noticing it in almost every website I visit now.
Cc: vangelis@chromium.org piman@chromium.org jam...@chromium.org
 Issue 302883  has been merged into this issue.

Comment 90 by kareng@google.com, 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 (https://codereview.chromium.org/25806002).
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 TestUFO.com 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?
Desktop
CPU: Intel Core 2 Q6600 (7 years)
GPU: nVidia GTX 460 (3 years)
Windows 8
Project Member

Comment 95 by bugdroid1@chromium.org, Oct 2 2013

Labels: merge-merged-1599
------------------------------------------------------------------------
r226615 | jbauman@chromium.org | 2013-10-02T23:30:08.107081Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/cc/scheduler/delay_based_time_source.cc?r1=226615&r2=226614&pathrev=226615
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/cc/scheduler/delay_based_time_source.h?r1=226615&r2=226614&pathrev=226615
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/cc/scheduler/delay_based_time_source_unittest.cc?r1=226615&r2=226614&pathrev=226615

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: https://chromiumcodereview.appspot.com/18589002

TBR=brianderson@chromium.org
BUG= 262437 

Review URL: https://codereview.chromium.org/25806002
------------------------------------------------------------------------
Project Member

Comment 96 by bugdroid1@chromium.org, Oct 2 2013

Labels: merge-merged-1599_59
------------------------------------------------------------------------
r226617 | jbauman@chromium.org | 2013-10-02T23:33:00.230781Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599_59/src/cc/scheduler/delay_based_time_source_unittest.cc?r1=226617&r2=226616&pathrev=226617
   M http://src.chromium.org/viewvc/chrome/branches/1599_59/src/cc/scheduler/delay_based_time_source.cc?r1=226617&r2=226616&pathrev=226617
   M http://src.chromium.org/viewvc/chrome/branches/1599_59/src/cc/scheduler/delay_based_time_source.h?r1=226617&r2=226616&pathrev=226617

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: https://chromiumcodereview.appspot.com/18589002

TBR=brianderson@chromium.org
BUG= 262437 

Review URL: https://codereview.chromium.org/25819002
------------------------------------------------------------------------
@terryhau - thank you!  Do you know the model of your display?  Is there just one plugged into the desktop or multiple?
Sorry

Desktop
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 kareng@google.com, Oct 2 2013

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Cc: scottmg@chromium.org
I can repro locally (my displays report 59Hz), building before/after 210101 to confirm.
I confirm that 210100 is relatively smooth on http://www.testufo.com/#test=animation-time-graph 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: http://www.testufo.com/photo
Data: http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/ 

Yes, the graph.

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

I switched from Firefox to Chrome just recently because Twitch.tv 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.  
https://www.google.ca/intl/en/chrome/browser/beta.html

It also fixes this problem.  
To the relief of people at http://www.reddit.com/r/tagpro/ 
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?
http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/
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:
http://www.testufo.com/#test=animation-time-graph&easteregg=1
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.

EXAMPLE: http://www.unrealengine.com/html5
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