Re: CSS animation perf statistics

Hi Kyle,

I like your suggestions, and I'd wish it would be that simple.. I'm going
to try and explain why it ain't.

Determining if something is hardware accelerated or not might work in
browsers like WebKit, where you actually do have a "hard" switch between
GPU and CPU. On browsers such as IE9+ however, there wouldn't be a point,
as everything is drawn using Direct2D if possible. It's also most often no
either/or, but rather "parts of it". Even in IE9, layouting (to my
knowledge) is still done in the CPU, and usually in other browsers, some
render paths disable GPU rendering as CPU rendering is actually more
effective sometimes. In an ideal world, the context switch wouldn't be
costly anymore and the devs wouldn't have to care. GPU/CPU should be an
internal engine decision.

That being said, I'm a big fan of performance statistics. It would only be
really hard to implement, and browser vendors would (sorry - ) most likely
tell you how their browser performs in an ideal scenario, when no memory
and CPU cycles are consumed by other apps. I'm right now experimenting
with the concept of micro benchmarks that can run in a very limited
timeframe before or during any app launch. This might be a better
indicator.

Am 13.06.11 15:36 schrieb "Kyle Simpson" unter <getify@gmail.com>:

>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).
>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
>    - 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
>
>
> 
>
>

Received on Tuesday, 14 June 2011 12:32:17 UTC