Hi, folks-
This is just a quick note to let you all know that the topic of APIs for
animation, both scripted and declarative, is one of the things that the
FX Task Force [1] (a joint task force between the CSS and SVG WGs) is
looking at, so we are following this thread with interest.
From a Recommendation-track spec perspective, animation (and by
extension, animation APIs and timing stuff) are already in scope for
those groups, so we would like to standardize things there; obviously,
we would want the continued participation of the WebApps WG participants
as well. (I prefer to avoid more painful chartering discussions.)
I'm not trying to cut off conversation here, I just wanted to make sure
people were aware.
[1] http://www.w3.org/Graphics/fx/
Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs
Gregg Tavares (wrk) wrote (on 11/15/10 6:03 PM):
following in the footsteps of a previous thread
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0223.html
I'd like to see if there is some consensus on this issue. Various people
are anxious to see this happen in more browsers.
A couple of questions came up for requestAnimationFrame
(see
http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html)
One is, how should this api be used if I want an app to update at 10hz.
It seems to be designed to assume I want the maximum frame rate. If I
want to run slower would I just use
setInterval(function() {
window.requestAnimationFrame();
}, 100); // request frames at 10hz?
That's fine if that's the answer
But that brings up the next question. I'm in some alternate world where
there is no Flash, instead all ads are implemented in Canvas. Therefore
a site like cnn.com <http://cnn.com> or msnbc.com <http://msnbc.com> has
5 canvases running ads in each one. I don't really want all 5 canvases
redrawn if they are not on the screen but the current design has
requestAnimationFrame and beforePaint to be window level apis.
That seems to have 2 issues.
1) All of them will get a beforePaint event even if most or all of them
are scrolled off the visible area since there is only 1 beforePaint
event attached to the window.
2) All of them will get beforePaint events at the speed of the fastest
one. If one ad only needs to update at 5hz and other updates at 60hz
both will update at 60hz.
Do those issues matter? If they do matter would making both
requestAnimationFrame and beforePaint be element level APIs solve it?
