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

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Sign in to add a comment

Implement something similar to mozPaintCount

Reported by, Dec 3 2010

Issue description

Chrome Version       : 9.0.597.0 (Official Build 67679) dev
Other browsers tested:
  Firefox4: OK

Currently, the only way to measure performances of Web browsers during animations is to check how often they are able to run javascript code (using for example)

It would also be useful to know how often the browser is able to paint a new frame.

In addition to giving Web developers another insight on the performances of their animation code, we would be able to see if the browser is sometime unable to paint a frame between two js runs, or wasting time painting twice the same frame between two js runs.

This is already possible in Firefox 4 beta through window.mozPaintCount, a property that keeps a record of the number of paints that occurred in a window.

It would be interesting to have the same counter available at window.webkitPaintCount in webkit.

Additional links:
"Measuring fps" by Robert O'Callahan of Mozilla:
"jQuery interval bookmarklet", a bookmarklet and a demo allowing to measure both "js runs rate" (fps) and "paint rate" (pps) during an animation in Firefox:
Labels: -Area-Undefined Area-WebKit

Comment 2 by, Dec 20 2010

Labels: Mstone-X
Labels: -Type-Bug Type-Feature
Status: Untriaged
Status: Available
This seems like something we're likely to discuss in the web perf working group.
It's been a year since the last comment. Any news on this? I'd be VERY interested in being able to use this in Chrome. Thanks in advance.
Note that window.webkitRequestAnimationFrame can be used measure performance as well.
Thanks, that does help to some extent, but I have to wonder if an artificial "paint count" built using RequestAnimationFrame would behave the same as a native webkitPaintCount implementation.
They're a bit different: mozPaintCount is incremented only when the page actually needs to redraw something, while webkitRequestAnimationFrame causes the provided function to be called as soon as the browser is ready to draw the next frame, regardless of whether anything else on the page needs redrawing.
I hadn't thought of that. This essentially means that webkitRequestAnimationFrame should not be used for benchmarking, right? I guess I'm back at square one. Unless we get webkitPaintCount :)

Comment 10 by, May 10 2012

Project Member

Comment 11 by, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 12 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Is there any news on this?  This was something that was marked for discussion in the web perf working group, did anything ever come of that?

This would still be an incredibly useful feature for delivering smooth animations.  (timers and requestAnimationFrame cannot deliver this type of information)

Comment 14 by, Jul 5 2015

Have you looked at the frame-timing API?

Would that provide the features you need?
I had not looked at the frame-timing spec, and that is exactly what I am looking for.  

What is the status of this spec, is there any review process define?  
I see that the spec is available in Firefox, is there a timeline for when this will be available in Chrome?

Comment 17 by, Jul 6 2015

I'm unsure of the current status of the frame timing spec implementation. The relevant bugs seem to be, 


Comment 18 by, Jul 6 2015

Status: WontFix
The mozPaintCount API is replaced by the frame-timing standard

Chrome is currently working on shipping the frame-timing API. The progress can be tracked in bug and the Chrome Status at

For this reason,I'm going to close this issue as the bug as WontFix.

Sign in to add a comment