requestAnimationFrame

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