- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Wed, 15 Jun 2011 07:13:26 -0700
- To: Sigbjørn Vik <sigbjorn@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Andrew Dupont <w3@andrewdupont.net>
Am 15.06.11 15:12 schrieb "Sigbjørn Vik" unter <sigbjorn@opera.com>: >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/#f >ps. >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. I love that. This would be a serious win if implemented across the board. > >-- >Sigbjørn Vik >Quality Assurance >Opera Software >
Received on Wednesday, 15 June 2011 14:13:57 UTC