- From: Andrew Dupont <w3@andrewdupont.net>
- Date: Tue, 14 Jun 2011 16:05:30 -0500
- To: public-web-perf@w3.org
Mine was one of the aforementioned TXJS talks, so Kyle asked me to weigh in. Let's imagine that there exists a set of animations that are only worth doing if you can be _somewhat_ sure they'll render at a certain frame rate. On mobile devices, most animations fall into this category. If I'm writing a web app that will only be consumed in MobileSafari, I know I can transition/animate "opacity" and "transform" and know they'll animate smoothly. But if my app will also be consumed by Android devices, I'm stuck; a few such devices support hardware acceleration, but most don't. On devices that lack support, I'd rather skip the animation altogether, because an animation running at 4 fps is worse than no animation at all. So my options are: (a) grit my teeth and animate in all browsers; (b) animate in no browsers; (c) whitelist certain browsers based on a UA sniff. There are serious drawbacks to all three options. So I'd love it if the "transitionend" property could include some metadata about the animation itself. Paul, you're right that a "used hardware acceleration" flag won't work — that was my initial idea, but smart people talked me out of it. I'd love to see a "frames per second" measurement, though. Browsers seem to have enough awareness of when they redraw for this to be feasible; Gecko, for instance, sports a MozAfterPaint event, and Chrome has an about:flag for showing the frames per second of animated content that uses composite layers. To me it's not a big deal if the numbers reflect an ideal scenario, or if they're best-guesses rather than certain truths, because I'm just trying to make an educated guess. Cheers, Andrew
Received on Tuesday, 14 June 2011 21:06:09 UTC