your feedback on the FPS counter

[egraether]

Hi all,

I have been working on the UI of the FPS counter in the compositor's HUDLayer and try to get some feedback.

(The FPS counter can be enabled with the --show-fps-counter command-line flag or in about:flags "FPS counter")

So far I improved the FPS counter along these points:

• cleaner look 
  
• adding transparency
  
• updating the numbers less frequent 
  
• indicator line at 60fps

These changes are currently in review and are about to get in.

See review and images. 

Please let my know if you have feedback on this.

Then I talked to people about what else can be done and built a few experimental prototypes based on some new ideas: 

• coloring the graph
  
• adding labels to the y-axis
  
• scaling graph
  
• displaying min/max values
  
• showing the compositor's target FPS
  
• drawing the graph time-based
  
• changing position of FPS counter

See screenshots and descriptions 

Currently none of these features is planned to get in.

If you think you totally need one of them or you have other ideas let me know.

Eberhard

[Ilya Sherman]

Are you planning to add this to the Developer Tools feature?  That seems better than keeping this behind a flag indefinitely, especially if you're going to be working on adding polish to it.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Mike Frysinger]

if its position is static, i might suggest using the upper right rather than left considering most content defaults to upper left and expanding from there ...

-mike

--

[Ilja Friedel]

+1 on upper or lower right.

[Eberhard Gräther]

I currently also work on enabling the FPS counter via the Developer Tools using a checkbox in the settings.

You can see the checkbox in this image: https://docs.google.com/a/google.com/folder/d/0B8Y78t3tjy1XVUhoRVA2cy1OTTQ/edit?docId=0B8Y78t3tjy1XZU1RSWlENTVJVTA

[Vincent Scheib]

The range that the majority of frames are in is pretty helpful. e.g. you could imagine a column of numbers in abreviated  form at one side of the widget:

max: 61

90%: 53

mean: 51

10%: 45

min: 13

to indicate:

Max frame rate (for any single frame in the displayed time window) is 80.

90% of the frames were at or slower than 60 FPS

The average was 55FPS

10% of the frames were slower than 45 FPS

The worst frame time was 13 FPS

The selection of 90% and 10% were fairly arbitrary, 95% and 5% are reasonable too.

Why? This helps tease out outliers and convey what users are mostly seeing. Producing numbers over the last period of time (instead of the last number of frames) avoids distorting the numbers based on the average FPS.

[Ojan Vafai]

I agree. I played around with it today and had the same issue. At that point though, you may as well have a proper histogram like chrome:histograms, but smaller. 

[Brandon Jones]

+1 on the request for a position other than upper left. If you want to be super-incredibly-mind-blowingly-awesome make the FPS counter draggable!

I would be careful about relying on graph color to convey information, as that frequently causes issues for colorblind users such as myself. The examples of colored graphs shown are actually okay for me, but that's primarily because the data represented by the color is largely redundant.

Finally, I like the idea of target lines, but I would caution against placing a static one at 60 fps and leaving it at that as not every device has a native refresh rate of 60hz. It would be nice if the FPS counter would query the displays native refresh rate and place the line (labeled) at that point instead.

On Mon, Nov 5, 2012 at 3:59 PM, Vincent Scheib <sch...@chromium.org> wrote:

[Eberhard Gräther]

@ Vincent Scheib

I agree that min/max numbers give a better understanding of what range the frames are in. Currently the standard deviation is used, which conveys the same, but much harder to read as you have to figure out yourself what 45.3 +/- 8.4 really means. I would like to go away from that, but I don't want to clutter the interface with too many numbers.

Your idea of placing a value of where the 90% and 10% mark is, sounds good. I'm not sure if it's easy to understand without explanation though. I will build a prototype if there is time.

Right now I think putting the absolute measured min/max value is a nice improvement and easy to understand. Also it makes it easier to interpret the graph, as you can better see which value is where.

@ Ojan Vafai

Putting a histogram there, seems a little over the top to me, but I imagine it being pretty awesome. A quick prototype might be nice as well.

@ Brandon Jones

Changing the position seems to stick, but with my patch landed yesterday, the display is now much smaller and slightly transparent, so this should be less an issue.

Dragging is almost impossible, because the FPS counter is part of the compositor.

The colors idea was just a way of conveying good and bad frame-rates, but I also see a problem here of where to put which color, as this might also depend on the device, besides your mentioned problem of colorblind users.

So, with my first patch that was landed now, there is a target line at 60fps. This might not be the super optimal solution. But I think it's better than putting no line at all and 60fps seems to be the most interesting number.

If the compositor runs in threaded mode then it tries to target a certain frame-rate that suits the device's display (if it gets a number, else 60). So what I could do is:

• show that number in the graph with an extra line
• change the 60fps line to that number
• put no 60fps line and only show a line if that number is available 

One other possibility is putting a line where the fps mean currently is.

Lots of options.

[Eberhard Gräther]

I have a new screenshot showing discussed features:

• top right!
• min/max fps instead of standard deviation
• histogram of graph data

https://docs.google.com/open?id=0B8Y78t3tjy1XMUZybFdyNzIyVDg

I aligned the histogram right beside the graph so both make use of the same y-axis and the data explains itself (hopefully).

I'm not sure if I treat the numbers the best way, I just put the measured fps values into buckets, so far.

[Brandon Jones]

Looking great! 

One question, out of curiosity: What's the lifetime of the min-max values? Many of my WebGL apps start up running at 2fps while content loads, then quickly jump up into the 30-60 range. I would hope that eventually the 2fps min would "fall off" the graph and I'd see the more meaningful runtime mins and maxes.

--Brandon

[Eberhard Gräther]

The min/max values update to what's currently in the graph, so old values fall off.

[shikha shrivastava]

Is it possible to add a logging mechanism for FPS numbers?

[David Spohr]

The counter is awesome, the only problem is you that you can't reposition it and/or quickly turn it off/on. I guess some kind of a keyboard shortcut would be best for this. I literally can't use it if I would see it on all pages, instead of just the one I'm working on.
Thanks a lot!