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

Re: CSS animation perf statistics

From: Kyle Simpson <getify@gmail.com>
Date: Wed, 15 Jun 2011 11:06:10 -0500
Message-ID: <395D742CADD54F1CBCD3548BD2E868CC@spartacus>
To: "Alex Russell" <slightlyoff@google.com>, "Paul Bakaus" <pbakaus@zynga.com>
Cc: <public-web-perf@w3.org>
I do think it's important to note in this conversation that the temptation 
is usually to put such requests into absolute buckets ("will always work 
exactly", "will never be (fully) accurate/reliable"). Those who are arguing 
against such stats are (correctly) pointing out that such stats are likely 
to always be somewhat fuzzy and implementation dependent (and thus belong in 
the "unreliable" bucket, in the strict sense of the term). But that's 
perhaps an unfair black-or-white type of argument.

I think it would be a fair characterization of Andrew's points in his TXJS 
talk that such stats would simply be useful *additional* data (in addition, 
say, feature tests) for libraries to try and make best guesses. The question 
is not really "can I get a perfect reliable guarantee of hardware 
acceleration?", it's instead "can I get a better hint than simply UA 
whitelisting that hardware acceleration is helpful or not for my intended 
CSS animations?" So, there needs to be at least a third bucket in the middle 
like "will (possibly) be informative but not contractually guaranteed".

For instance, being able to monitor the average framerate of animations over 
the lifetime of a page might allow an animation library to adjust its 
approach as conditions vary (maybe higher CPU utilization at some point 
means the framerate goes down, so the library adjusts its method during that 
time, etc).

>From the difficulties that Andrew has expressed during his development of 
Scripty2, I get the impression that replacing JS animations with CSS 
animation equivalents is quite hairy, and the majority of the open web would 
probably look at it as nearer to "rocket science" in terms of difficulty of 
managing all the various factors. Of course, as a library author, a common 
goal is to try and simplify and smoothe out a lot of such messes so 
end-users can more effectively take advantage of it. So, if a library can 
keep the user from having to worry about such details, this helps both the 
user and the library do their jobs more effectively.

I think such stats would assist such a library in making better guesses as 
to the best approach for a requested animation.

Andrew said in his talk that he essentially gave up on the proposition of 
the animations being perfect in all situations, and is instead going for 
good-enough or best-attempt. This is most often the case in general web dev 
and certainly in library authoring, and that's exactly what these types of 
stats would go to: best-attempt guesses.


--Kyle
Received on Wednesday, 15 June 2011 16:06:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 June 2011 16:06:58 GMT