W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

Re: CSS animation perf statistics

From: Kyle Simpson <getify@gmail.com>
Date: Fri, 8 Jul 2011 10:52:28 -0400
Message-ID: <E2A56CFCB94044CEA039A09DF64B76D6@spartacus>
To: <robert@ocallahan.org>, Sigbjørn Vik <sigbjorn@opera.com>
Cc: <public-web-perf@w3.org>, "Andrew Dupont" <w3@andrewdupont.net>
> My main worry is that you can only really discover whether or not you can 
> play the animation by actually trying to play it. But starting to play it, 
> then suddenly turning it off, is likely to not be acceptable.

If we expose the current average FPS to JavaScript, then responsible 
animation libs (like Scripty2) can monitor that value throughout the 
lifetime of the page to try and make the best balanced decisions about how 
to run animations...

For instance, if a user requests a taxing animation A, and it is caused to 
start running, and while it's running, animation B is requested... then the 
lib could see that the FPS is lower than the acceptable threshold, and so 
for B, use a different approach... whereas if either A or B is requested by 
itself, the FPS may in fact be acceptable enough.

Bottom line, exposing the running average of FPS to the page allows a 
responsible lib to tailor the behavior to the running conditions of the 
page, accepting that such conditions may go up and down, and that the lib 
should be able to detect such things.

With that in mind, I don't think a one-time check like a media-query is 
sufficient. But perhaps it might be if that media-query is re-evaluated each 
time it's requested -- not sure if that's how media-queries work or not.

I will say this, though... the point of this request is that a lib can 
decide if a CSS animation is sufficient, or if it should pick a fallback, 
like JS animation... so there'd have to be some way to programmatically 
decide that the media-query failed, so that the lib could substitute a 
different approach.

--Kyle
Received on Friday, 8 July 2011 14:53:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC