- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Wed, 15 Jun 2011 15:12:51 +0200
- To: public-web-perf@w3.org, "Andrew Dupont" <w3@andrewdupont.net>
On Tue, 14 Jun 2011 23:05:30 +0200, Andrew Dupont <w3@andrewdupont.net> wrote: > 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. Opera experimented with some related technology some time ago, see http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/#fps. Those demos still work in Opera 11. That gave the developer currentFPS and targetFPS properties to play with. A similar setup could be included in e.g. CSS, imagine the following: @media (min-fps:30) { body { transition-property: opacity; transition-duration: 2s; } } Of course, a currentFPS property could additionally be added to the RequestAnimationFrame specification. -- Sigbjørn Vik Quality Assurance Opera Software
Received on Wednesday, 15 June 2011 13:13:36 UTC