Framerate counter in debug panel instead of stacked frametime chart

[robboerman]

To be able to analyse impact of changes to the application and CAAT itself on the user experience I think an accurate framerate counter is needed. Charting the frametime is somewhat less useful to analyse the perceived speed of the application. Especially for mobile deployment framerate analysis is crucial.

Changes:
Added framerate counter to Debug panel including minimum and maximum levels
Changed stacked frametime chart into framerate chart which is easier to read
minor change the RAF chart (plotting from t-0.5 to t

[hyperandroid]

Hi Rob,

your suggestion is good depending on what you'd like to see in the graph. I'm happy with the idea of milliseconds spent per frame, in its different form (either javascript or RAF). That means more plots per second if more frames can be processed in that second.
The framerate counter is definitely a nice addition.
Also, adding controls for enabling BBoxes, sound and music could be handy.
I think, we could make this plot a dual functioning mode selectable by the user, either show frames per secod, or time spent on each frame.

What do you think ?
-ibon

[robboerman]

Hi Ibon,

The number of milliseconds is indeed almost the inverse of the framerate. Personally (from a game development point of view) I like the framerate better because it reflects the user experience, it is the user-perceived end-result of all processing. I don't see what the milliseconds spent per frame adds to that when analyzing the speed of the game.

After committing the changes I made some more adjustments because I saw that the debug chart itself takes up too many resources (even on desktop). Therefore the numbers the debug panel is reporting are distorted, much worse than what you would get when not running the debugger (my profiler reported 50% spent in the debug's paint method). Wouldn't it be better to set a refresh interval on the entire debug panel such that it does not redraw (moving the drawn chart back and adding 1 tick) every game frame? Locally I have changed that already and the game is now steadily reporting around 60 fps on my desk top instead of 30 before the change.
In that case we should decide what to draw:

• on update of the chart, draw the entire statistics history
• on update of the chart, only draw the current statistic with a interpolated line the previous one.

What do you think?

Met vriendelijke groet,

Rob Boerman
rob@robboerman.com
twitter: @robboerman

http://appointsolutions.com

Op vrijdag 13 januari 2012 (w2), om 12:35 heeft hyperandroid het volgende geschreven:

Hi Rob,

your suggestion is good depending on what you'd like to see in the graph. I'm happy with the idea of milliseconds spent per frame, in its different form (either javascript or RAF). That means more plots per second if more frames can be processed in that second.
The framerate counter is definitely a nice addition.
Also, adding controls for enabling BBoxes, sound and music could be handy.
I think, we could make this plot a dual functioning mode selectable by the user, either show frames per secod, or time spent on each frame.

What do you think ?
-ibon

---

Reply to this email directly or view it on GitHub:
#24 (comment)

[hyperandroid]

Been playing with this info view. Will merge your additions and make some modifications over it.

[robboerman]

Hey Ibon, great, looking forward to seeing it.

Any thoughts about reducing the paint overhead of the debugger?
Reducing the amount of paint calls really improves the debug load.

Met vriendelijke groet,

Rob Boerman

Op Jan 13, 2012 om 20:01 heeft hyperandroid
reply@reply.github.com
het volgende geschreven:

Been playing with this info view. Will merge your additions and make some modifications over it.

---

Reply to this email directly or view it on GitHub:
#24 (comment)

[hyperandroid]

Hey Rob,
just pushed some changes to the Debug object.
Take a look at the file located at documentation/debug/debug_template.html where you could find the needed html code for the debug object to work.
Let me know how it works for you.

-ibon

[robboerman]

Hi Ibon,

Great, looks much better! I created another pull request based on your changes to improve it a bit for mobile screens and remove the need for debug markup in your HTML file.

Met vriendelijke groet,

Rob Boerman
rob@robboerman.com
twitter: @robboerman

http://appointsolutions.com

Op zaterdag 14 januari 2012 (w2), om 01:01 heeft hyperandroid het volgende geschreven:

Hey Rob,
just pushed some changes to the Debug object.
Take a look at the file located at documentation/debug/debug_template.html where you could find the needed html code for the debug object to work.
Let me know how it works for you.

-ibon

---

Reply to this email directly or view it on GitHub:
#24 (comment)