- From: Kyle Simpson <getify@gmail.com>
- Date: Wed, 15 Jun 2011 11:06:10 -0500
- 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 UTC