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

Re: CSS animation perf statistics

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>
Message-ID: <op.vw4cbpsppi0hod@id-c0735.oslo.osa>
On Tue, 14 Jun 2011 23:05:30 +0200, Andrew Dupont <w3@andrewdupont.net>  

> 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  
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC