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.
Related
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!
using:
Chrome 36.0.1985.125
Foundation Orbit 5.2.2 with animation: slide
I have a slide show, 5 slides, at the top of my page. They are set to transition via slide every 3000 ms.
I first noticed the repaint issue described below due to Fancybox being called near the bottom of the page. While the Fancybox iframe was "popped out" there would be a quick white flash / flicker affecting everything apart from the iframe, every 3 seconds.
Using Chrome's inspector's Timeline view as well as the Rendering option to "Show paint rectangles" proved my suspicions correct.
Even when the slide set (the top of the page) is off screen, still every 3 seconds there is a page-wide repaint. With the inspector's Timeline, I can see a "heartbeat" every 3 seconds in the flow, even when scrolled all the way to the bottom of the page, including a large purple and green spike, where purple represents rendering and green represents painting. With the Rendering option "Show paint rectangles" I see, again even when scrolled all the way to the bottom of the page, a quick flash of every element on the page framed and tinted in green (being painted) every 3 seconds.
I've looked around quite a bit for "foundation orbit flickering," "orbit slideshow repaint" "foundation orbit repaint offscreen," and similar terms and have so far not discovered anything of use.
One or two pages I read mentioned a font change or font flicker at regular intervals relating to the slides' transitions. The "fix" (or workaround) there was to change the animation parameter's value from slide to fade. Trying this, I found that the repaint issue went away completely. However, I would prefer to use the slide transition.
I haven't been able to reproduce this in Safari or Firefox, but I also don't know what developer tools to use in either of those browsers that would confirm or deny whether the repaint is occurring (i.e. the equivalent of Timeline or "Show paint rectangles" in Chrome's inspector). Failing that behind-the-scenes proof, it is the case that in Firefox and Safari, with the Fancybox iframe popped out near the bottom of the page, there is no white flash / flicker, as there is in Chrome due to the repaint.
Any help would be greatly appreciated.
And yes, I realise that the Foundation Orbit slideshow is no longer supported.
Many thanks.
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.