RenaudRohlinger / stats-gl

https://stats.renaudrohlinger.com/
167 stars 7 forks source link

Question: Possible PR #2

Open belsrc opened 11 months ago

belsrc commented 11 months ago

Hello, I was wondering if you would be interested in a pull request. I currently use this lib with deck.gl and have a number of custom panels. The current rolling max was leading to some confusion. So I added an additional parameter to the Stat and Panel constructors. This facilitates setting a static max flag so that max/maxGraph are always the highest value seen instead of a re-averaged value as they fall off of the array. (here & here).

Altered the demo to pipe the current mouse X into a custom graph.

Current rolling max: curr-a curr-b

The image is moving from the left to right and back. The graph always being "maxed" has the potential to, I guess, hide what the history really was.

With both of the static max flags: new-a new-b

The graphs have a more relative visualization. If one would prefer the internal (FPS/CPU/GPU) graphs to be as is but custom to be static (on a per Panel basis). Thats possible too.

mix-a mix-b

Would this be something you would be interested in? Don't want to PR if it is something unwanted.

RenaudRohlinger commented 11 months ago

Interesting! I would be interested in such an option, also I wonder if we shouldn't add another parameter in that case such as initIgnoredFrames to prevent having irrelevant boundaries when the shaders get compiled when starting the app.

That new parameter would prevent the first x frames from getting into account and setting up unrealistic maximum boundaries. Because if I understand correctly your setting, the max that will be way too high from the initial compilation of the program will stay forever too high and does not get reequilibrate afterward)

belsrc commented 11 months ago

That's also a good thought, as in the image, the CPU variation spikes on initial load so isn't necessarily indicative of the "running" load on that particular graph. FPS and GPU don't appear to suffer the same problem as much, but it also wouldn't hurt them.

I'll play around with that option on my branch and open up a PR so we can continue the discussion directly on the changes. Thanks!