Allow Stats class to track a time window.

[tsherif]

Deck usage requires gathering measurements that only become visible after a certain number of measurements. The Stats object should support this usage. I think the simplest way to do this would that the Stats object should have a windowSize property. Calls to stat updates like incrementCount, addTime, etc. should only update private members _count and _time. count and time properties would only be updated when _count % windowSize === 0.

@Pessimistress this should support the usage you need for Deck without _onMetrics.

[Pessimistress]

Is the window size by count or by seconds? In the deck use case, we want the time window - I guess it's fine if we have >60fps and just extract HZ from the last 60 bumps, but if we have <10fps we definitely want to know if things improved during the last second.

[tsherif]

I'd prefer to do it based on count, because that would be a consistent sampling. Is there a reason why it has to be the last 1s vs 60 frames, however long it took to get that many?

[Pessimistress]

My understanding is that the Stats class does not have the built in notion of "frame". The last 60 calls to incrementCount may happen at 1fps, 1fps, ... then increase to 10fps. What do I get when I call getHZ() in this case?

[tsherif]

For FPS, it will give you the average over those frames. I think it makes more sense to base it on the count for two reasons. If based on time:

• You'll be comparing between different sample sizes.
• You'll be comparing between different times because the timing can't have resolution < 1 frame.

Could you provide some more detail about how you want to use these metrics? I might not be understanding something about what you need to do.

Another thought is that if you want more detail, the frame timers offer more information than the FPS.

[Pessimistress]

Ok you have a point. I think this will work fine since it is brand new API. As long as the behavior is clearly documented, we can always adapt if new use cases appear.

[tsherif]

One final idea: would it be helpful to get the min and max over the window? We could do this pretty easily by tracking minTime and maxTime across the window for the time metrics and providing getMinHz and getMaxHz methods.