[AnimationSmoothness] Drive-by feedback about the animation smoothness proposal

[noamr]

Animation smoothness is a tough one, because it combines the need to measure it statistically over time, react to changes, and also not create too much overhead, either by over-measuring or over-reporting to the timeline.

Following the explainer and the several good alternatives presented there, I would suggest to go with something along the line of a bespoke observer (not a PerformanceObserver that works on the performance timeline) that can be started, stopped, queried for statistical information, and fire events when certain thresholds have been passed.

Something like:

const observer = new FrameRateObserver();
observer.granularity = 10;
observer.start();
observer.stop();
observer.stats(options);
observer.addEventListener("change", event => { ... })

This can be built as a polyfill on top of requestAnimationFrame, but having it in the platform can have a much lower overhead which in this case is important enough.

Hope you find this feedback helpful and please keep at it, it's a great problem to solve!

[noamr]

/cc @jenna-sasson @aluhrs13

[kurtextrem]

I don't have browser-level insights into the PerfObservers, but what makes it different to the API you propose? Why couldn't the animation smoothness observer run lazily, e.g. only if something observes it, it actually collects the data? Or does anything added to the PerfObserver API cause overhead (e.g. IPC or something)?

I like the granularity idea though, that is probably harder to achieve with PerfObservers alone (because it would introduce a new option just for the animation smoothness proposal; maybe it isn't too bad though?)

[noamr]

I don't have browser-level insights into the PerfObservers, but what makes it different to the API you propose? Why couldn't the animation smoothness observer run lazily, e.g. only if something observes it, it actually collects the data? Or does anything added to the PerfObserver API cause overhead (e.g. IPC or something)?

The overhead is mostly because frame rate is something that can change very often, it's not a moment in time when something happens but rather an ambient metric that feels more like profiling or RTCP.

Also performance observers are not built in a way to respond to them immediately to change the UI but rather as something you beacon to a server...

Having said that, this is not a technical limitation of performance observers, it's more of an API design consideration.

You probably mainly want to measure frame rate statistically over a period of time and have some moving-average threshold event or that sort of thing I think?

I like the granularity idea though, that is probably harder to achieve with PerfObservers alone (because it would introduce a new option just for the animation smoothness proposal; maybe it isn't too bad though?)

Having a new option is not a problem in itself and event timing has something similar.

[kurtextrem]

You probably mainly want to measure frame rate statistically over a period of time and have some moving-average threshold event or that sort of thing I think?

Yeah, that comes pretty close to my use case. Basically treating FPS as one of the important UX metrics, so having a (moving-)average works for that. But I can also see the use case of actively monitoring FPS during animations or expensive renders (so you can adjust on the fly how many things you animate)