929114 - Live Frame Rate Visualization

Status: RESOLVED FIXED

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Axel Kratel]

As a developer, I'd like to be able to have access to a live visualization of the frame rate of my application so that I can run my application in different ways and see how my interactions with the application affects the frame rate. 

Acceptance Criteria:
* Browser instruments the frame rate
* Instrumentation has minimal impact on performance
* Tools provide a basic visualization of the frame rate that shows developers what is going on with the frame rate as they interact with their developers

Notes:
The best analogy here is to think of a car mechanic that listens to the car's engine or looks at instrumentation attached to the car to be able to diagnose what is going on. Our visualization needs to be intuitive enough to allow developers to really be able to tune into the graphical performance of their app.

Example: see Shumway inspector.

Comment 1

[Paul Rouget [:paul]]

in about:config: layers.acceleration.draw-fps -> true

This will draw the frame rate in a box. This is obviously not ideal, but the internal mechanism is here.

Comment 2

[Rob Campbell [:rc] (:robcee)]

Paul, do we have access to the numbers this pref exposes? Like, does the Box live in the Chrome's DOM somewhere? Would be useful for graphing.

Comment 3

[Paul Rouget [:paul]]

(In reply to Rob Campbell [:rc] (:robcee) from comment #2)
> Paul, do we have access to the numbers this pref exposes? Like, does the Box
> live in the Chrome's DOM somewhere? Would be useful for graphing.

It's not exposed at the JS level. The box is an extra layer. So this information is not accessible. I don't think it'd be hard to expose this information, but probably not in a "live" way (compositing has its own thread). But I don't think the info is always available (non accelerated compositing doesn't seem compatible). I'll look at this.

Comment 4

[Paul Rouget [:paul]]

A simple FPS counter doesn't bring any meaningful information. Often, compositing doesn't happen because it's just not needed. And an async frame might not need to be drawn because it's hidden. What we want is to know when a frame is missed because of a blocking operation. And we need to know what this operation is. A timeline sounds much more appropriate the a FPS counter.

And here we reach the limit of my understanding of the platform. Cc'ing Benoit.

Comment 5

[Benoit Girard (:BenWa)]

That's a good summary.

Comment 6

[Rob Campbell [:rc] (:robcee)]

I agree that a single framerate number is not very useful unless you're willing to watch it constantly. A line graph over time would probably give you better visual feedback that something slowed down. You could "perform an action" and see that 2s ago, there was a dip in the graph. This might lead you to try the same action in the profiler which could in turn show you some details of the slowdown.

Comment 7

[Benoit Girard (:BenWa)]

I added scroll-graph which gives better results then FPS but is a bit harder to read:
http://benoitgirard.wordpress.com/2013/12/06/introducing-scroll-graph/

But not a direct solution to this bug.

Comment 8

[Jordan Santell [:jsantell] [@jsantell]]

I believe the new performance tool meets all this acceptance criteria -- closing