I have a game I am developing for a client. Its not a particularly intensive game graphically but it does have quite a few different animations and a large number of textures. It seems that there is a threshold for the number of different spritesheet based animations that I have have in Chrome. When I go beyond that point (about 5 different animations) the FPS tanks to about 5FPS.
The weird thing is the game runs at a solid 60FPS all the time in Firefox with no problems.
It appears that it something to do with the way Chrome does hardware acceleration of the 2D canvas.
Note this video of the game, the game runs at a silky smooth 60FPS (see bottom right for FPS counter) when the game is smaller than about 220px high, but as soon as its even a little higher than that then it runs at 5-10FPS:
https://www.youtube.com/watch?v=3VWo6eQmy1g&feature=youtu.be
I think its got to be related to this issue:
https://code.google.com/p/chromium/issues/detail?id=170021
It says fixed but I dont think it is.
Does anyone have any more info on this?!
Cheers!
Related
I'm playing a web game on Chrome, and this game has some pretty slow menu animations.
As far as I know this game is made in html5.
I would like to know if somehow there is a way to increase the framerate on Chrome so the animations on the game would go faster.
Thanks.
Disabling hardware acceleration on Chrome setting could somehow help.
My app draws same figure on the canvas multiple times. We figured out that we could draw it once on the hidden canvas and them just copy it to the target canvas. I am doing some perf comparison. And I am facing some weirdness that I can't explain.
Here it is in a nutshell: I have a test with two canvases of the same size. In the first canvas I draw figures multiple times. On the second: I draw on the hidden canvas first, then I copy it into visible canvas. The result should be the same.
Here is the fun part: Approach with hidden canvas works fine with size of the canvas 400x164. It is 60% faster that drawing each figure separately.
But once I increase size by once pixel to 400x165 - bam! Stamping is 60% slower in Chrome. In IE it is still faster (ask me how I found out that 164-165 threshold).
Here are the links to JsPerf tests:
size 400x165: http://jsperf.com/draw-vs-stamping/7
size 400x164: http://jsperf.com/draw-vs-stamping/8
Chrome 46.0.2490.80 32-bit on Windows Server 2008 R2 / 7 64-bit
Any help is appreciated.
The answer is this and it is unfortunately stupid. I've been baffled by this for years. Your question helped me find the answer.
If and only if a canvas contains >= 60,000 pixels, will Chrome allow hardware acceleration.
I had a 200x200 mini-map sitting ontop of a webgl app. The webgl app would be rendering 150,000 polygons no problem at 60fps. Once the player began moving, the framerate would drop to ~30fps. Disabling the minimap would keep things at a smooth 60fps. I was surprised my tiny little super basic minimap would cause such a massive hit.
After searching on SO for a solution (and not really finding one), I began playing with the posted jsfiddles. Canvas size seemed to make all the difference. In one particular fiddle (from HTML5 drawImage slow on Chrome), I tried a size of 256x256 (area of 65,536), ran terribly. Tried 257x257 (area of 66,049) ran roughly 6x faster...
So I tried my minimap at 257x257 (used CSS zoom to shrink it down to the appearance of original size). Ran great, almost 0 performance hit when moving.
So there it is. Google chose a threshold of 60,000 pixels in order for hardware acceleration to kick in.
Annoying.
Version 63.0.3239.84 (Official Build) (64-bit)
I'm currently putting together a website on bluehost, and we have an animated GIF for our home page. The GIF is around 450KB in size, with a resolution of 1500 x 600. Currently the webpage is simple with the GIF on it and a few buttons that dont really do anything. The GIF lodas nice and smoothly, but when I observe my system resources, that Chrome tab start to spike in memory usage, and goes pretty much all the way up to 750MB. (WHICH IS RIDICULOUS).
We have tried this on many different platforms and the same result occurs. We tried using other browsers, but do not come across this problem. I understand that the GIF has a large resolution, but I still find it ridiculous that it consumed that much memory space. Anyone had this problem before?
http://jsfiddle.net/2247N/
I made this jsFiddle that uses EaselJS from CreateJS to update a simple canvas on defined frame rate of 60 FPS. There is just a simple circle on the stage, so I would expect the FPS label to show constant 60FPS on every browser. But here's what I've found:
Chrome: FPS: 60.82474226801933
IE: FPS: 60.095788862740555
Firefox: FPS: 43.2232327656598
Why not also 60FPS in Firefox? I am using Firefox 29.0.1. No other tabs were opened, cache was cleared, window was active, no other applications were running.
In case someone still has this problem, try removing the shadows on all objects because Firefox is performing poorly when it's trying to render shadows on the canvas. More information here:
slower canvas speed seems to be a trend with Firefox.
On my machine, I get a solid 59-60, but for best practices, you may want to use requestAnimationFrame as 2astalavista mentioned in conjunction with setting FPS. To do that in CreateJS, just set the timing mode to RAF_SYNCHED:
createjs.Ticker.timingMode = createjs.Ticker.RAF_SYNCHED;
createjs.Ticker.setFPS(60);
Documentation on Timing Modes: http://www.createjs.com/tutorials/Animation%20and%20Ticker/
Updated Fiddle: http://jsfiddle.net/2247N/1/
I'm doing some d3.js visualization development (mostly SVG) and I was measuring the FPS of my transitions using the "Show FPS meter" option in the web tools. Strangely, the FPS appears to be capped at exactly 30fps. Other colleagues using the same version of Chrome consistently get 60fps running the same code.
I can get a higher frame rate out of other browsers and out of Flash so it seems to be something Chrome specific.
Does anybody know what kinds of things might cause Chrome to clamp the frame rate at 30fps? I've read that it might do this if it thinks that a smooth 30fps will look better than a choppy 60fps if there is a lot of variance, but I don't understand why it would need to do that on my fast desktop machine.
Here's an example page that shows the problem:
http://mbostock.github.io/d3/talk/20111018/collision.html
Drag your mouse around and you'll probably see the FPS counter sit around 60fps. On my machine, it sits at precisely 30fps.
I've tried Canary with the same results.