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.
Related
I am playing with Chrome's FPS meter, but have some difficulty understanding it.
My understanding is Chrome targets 60 FPS, and the higher, the smoother.
However, I see the frame rate drop to 1 fps on some sites, but I do not feel it's sluggish.
For example,here's screen shot on google's own search page.
the frame rate is 4.7 fps,
and then when I start scrolling the page, the rate seems goes up to 30 or even sometimes 59.
The page is very responsive in the whole process.
So how to use this frame rate? Seems useless for monitoring page smoothness.
The Google Search page is (while you are not scrolling) static. The only dynamics are hover links but it features no animations for example react components. Therefore Chrome does not have to render the page at 60 fps to save power.
Try it for yourself if you visit a site with animated objects like this site
You can see that chrome really only renders new frames when its forced. So if your animation requires constant 60 fps chrome would render them, but if its an animation with pauses (like in the example page) chrome tries to minimize the used power.
I'm normally develop on hi-dpi machines (a Macbook Pro, 2018 MBA, iPhone, Pixel 2 XL). Often I'm styling something or drawing a diagram and I need to know how it's going to look when displayed on a low-dpi machine (pre 2018 Macbook Air, majority of PCs, etc...)
I tried using Chrome's devtools device emulation and it let's you set a devicePixelRatio but it's still actually rendering text and SVGs and styles in hd-dpi. (Not really sure what that setting is doing. I made to custom settings, one 1280x780 dpi = 2, and another 1280x780 dpi = 1 and switching between them changes nothing. My guess is it only changes what "windows.devicePixelRatio" and maybe what images load if using srcset and css media queries.
Is there a way to simulate low-dpi in Firefox or Chrome? Basically to get the browser to render at 1/2 the resolution and then expand with nearest neighbor filtering. I realize it will not be a perfect representation but my hope is it's good enough to check that thin lines in a diagram for example are still readable.
Well I figured out one way, at least on Mac.
Turn on OS Zoom in Settings under Accessibility
Be sure to uncheck "Smooth images". Then in Chrome or Firefox set the zoom level to 50% and turn on the OS level zoom Option+⌘+8
This does a pretty good job of looking like a low-dpi display.
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 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!
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/