Bug 176928 – [GTK][WPE] Improvements on the FPS counter

• Component: WebKitGTK
• Status: NEW

[Carlos Alberto Lopez Perez]

Currently its possible to make WebKit draw a tiny FPS counter on the top-left corner of the WebView if the environment variable WEBKIT_SHOW_FPS is exported.

The value passed to this variable is used as the interval to calculate/update the FPS (each X seconds). See r142524 <http://trac.webkit.org/r142524>

However, the font size used by default (8 points) is sometimes not big enough (specially when doing some demo on a big screen).

So it will be nice to be able to configure at run-time the size of the font.

At the same time, when doing this tests on a machine meanwhile you work via SSH it will be much more convenient to get the value also printed on the terminal.

[Carlos Alberto Lopez Perez]

Created attachment 320797 [details]
Patch

[Carlos Garcia Campos]

My plan was to move the FPS counter to the resources overlay. What do you think?

[Carlos Alberto Lopez Perez]

(In reply to Carlos Garcia Campos from comment #2)
> My plan was to move the FPS counter to the resources overlay. What do you
> think?

Adding there an FPS counter is a good idea.

However the use case here is a bit different. The use case(s) for this are:

 * Use case 1: [Exporting detailed data]
   Log the info easily to a text file for further analysis. So exporting some environment variables and redirecting stdout/stderr to a text file via SSH is perfect. The info that the resource overlay prints can already be get into other text file with the memory_sampler.

 * Use case 2: [Script-able behaviour]
   Start the counter as soon as the browser is started without having to require any user keyboard input. Exporting an env variable from a SSH session is easy, pressing ctrl+alt+g not so easy to do remotely. For preparing a demo is easier to have a script ready with some environment variables exported than requiring the one starting the demo to press some keys.

 * Use case 3: [Configurable font-size at run-time]
   On some big screens (TVs) the current FPS counter is a bit smaller than desired and is hard to read correctly if you don't get close enough to the screen. Likely it will happen the same with the resource usage counter.


Do you think this patch is incompatible (or complicates) your plan of adding a FPS counter to the resource overlay?

[Carlos Garcia Campos]

(In reply to Carlos Alberto Lopez Perez from comment #3)
> (In reply to Carlos Garcia Campos from comment #2)
> > My plan was to move the FPS counter to the resources overlay. What do you
> > think?
> 
> Adding there an FPS counter is a good idea.
> 
> However the use case here is a bit different. The use case(s) for this are:
> 
>  * Use case 1: [Exporting detailed data]
>    Log the info easily to a text file for further analysis. So exporting
> some environment variables and redirecting stdout/stderr to a text file via
> SSH is perfect. The info that the resource overlay prints can already be get
> into other text file with the memory_sampler.
> 
>  * Use case 2: [Script-able behaviour]
>    Start the counter as soon as the browser is started without having to
> require any user keyboard input. Exporting an env variable from a SSH
> session is easy, pressing ctrl+alt+g not so easy to do remotely. For
> preparing a demo is easier to have a script ready with some environment
> variables exported than requiring the one starting the demo to press some
> keys.
> 
>  * Use case 3: [Configurable font-size at run-time]
>    On some big screens (TVs) the current FPS counter is a bit smaller than
> desired and is hard to read correctly if you don't get close enough to the
> screen. Likely it will happen the same with the resource usage counter.

I think the resource overlay should look ok in any screen, but if it doesn't I don't think we should add any env var to change it, we should do that automatically based on the screen resolution or whatever.

> 
> Do you think this patch is incompatible (or complicates) your plan of adding
> a FPS counter to the resource overlay?

Sure, this patch should actually be split, I was referring only to the part that improves the readability of the on screen fps counter. I'm fine with adding a way to show fps on stdout/stderr, but I think it belongs to a different patch. So, this what I would:

1- First of all I would check if the way we are currently counting the fps is correct or at least the best one. I'm not sure it is, it's something I was going to do when moving it to the overlay.

2- Rename this bug and limit it only to show fps on stdout/stderr, using the same env var we are currently using, when present we show the info.

3- Move the fps to the resource overlay in a separate bug/patch.

Maybe it would be a good idea to add an env var to start the browser with the resources overlay open too, but that would also be a different bug.