Re: CSS animation perf statistics

On Tue, Jun 14, 2011 at 5:31 AM, Paul Bakaus <pbakaus@zynga.com> wrote:

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


Note that Direct2D doesn't necessarily use hardware for everything either
(nor should it). Many windows systems will get software rendering for
*everything* in the UI.


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