Re: CSS animation perf statistics

On Mon, Jun 13, 2011 at 6:36 AM, Kyle Simpson <getify@gmail.com> wrote:

> At the TXJS conference over the weekend, several talks were dedicated to
> the topic of using CSS transitions and animations to replace the more clunky
> (and often less performant) JavaScript animation approaches of many
> "effects" done on web pages.
>
> But, noted was that not all systems benefit from this approach (namely,
> those which do not have the ability to hardware accelerate such things).


That's not an entirely accurate characterization. Even in systems that are
"hardware accelerated", the smoothness of animation and the ability to be
decoupled from page layout is implementation (and to some degree, spec)
dependent.

Further, if libraries don't need to include their own animation code and
would achieve equivalent frame rates, needing less code is an out-and-out
win.


> The observation is that libraries like Scripty2 (and others) which try to
> detect which (best) animation method(s) to use could benefit from an
> interface in the content-JavaScript which allows them to detect such things:
>
>   - are CSS transitions/animations hardware accelerated
>

This isn't really meaningful. You want to know something more like "will
*this* animation get a good frame rate?" since GPU texture limits, reflow
implications, etc. can all play a part in defeating "hardware acceleration".


>   - what is the (avg/min/max) framerate of the transitions/animations on
> the page (the currently executing one and/or the most recently executed one)
>   - the CPU usage stats for the current or previous animation(s)
>   - etc
>
> The benefit for this type of information is that a library author can
> determine from such stats that a device will or won't (likely) benefit from
> offloading an animation to CSS as opposed to JavaScript (setInterval() or
> requestAnimationFrame, etc).
>
> I just wanted to ask if such data is already exposed, or planned to be
> exposed, in any interface, or if it's agreed that this type of data would be
> useful and relevant to expose to the JavaScript layer?
>
> --Kyle
>
>
>
>
>
>