Proposed charter text for Display Paint Notification vs requestAnimationFrame

Hi,

I'm excited about standardizing something like requestAnimationFrame but I
noticed that the proposed charter text for display paint notifications at
http://www.w3.org/2011/02/webperf.html doesn't really describe how
requestAnimationFrame works.  Some of the differences are a bit subtle and I
think it's worth some discussion to ensure that we know which problems we
want to solve with this API and that we can come up with an excellent
solution.  In particular, I think some of the performance monitoring use
cases that have been mentioned are not fully compatible with an
implementation of requestAnimationFrame that works best for imperative
animations.

The text at that page currently reads: "Display Paint Notifications: An
interoperable means for site developers to be notified when the user agent
needs to repaint the screen." which describes something close to
requestAnimationFrame.  With requestAnimationFrame the page registers a
callback or set of callbacks to be invoked "soon", normally just before the
next repaint.  However, there are cases where a quality implementation of
requestAnimationFrame will repaint the screen without invoking the
requestAnimationFrame callbacks and there are cases where a UA will invoke
the requestAnimationFrame callbacks without actually repainting the screen.

For the first case, consider a page that had a video with a target framerate
of 30FPS and a callback that takes on average 50ms to run.  It's clearly
impossible to invoke the callback on every frame and sustain 30FPS on the
video and in my opinion a UA should favor the video in this case, which
means on average the callback will be invoked 2 times for every 3 frames.  A
similar situation exists for declarative animations which in some browsers
can be updated from a different thread than the one processing the main
event loop.  If such an animation is in progress, a UA should probably
continue to produce frames at the appropriate framerate for the system
(typically 60FPS) and invoke the callbacks as fast as the page can handle
them.  It's tempting to just say that a page author should make their
callbacks run "fast enough", but that's difficult to ensure in practice with
diverse hardware and JavaScript engines.  Even on the fastest hardware with
the most advanced JavaScript engines currently shipping it's nearly
impossible to completely prevent GC pauses longer than 16ms.

The second case depends on some browser implementation details, but is
likely common enough to merit covering in the standard.  In WebKit, the
browser will only repaint the screen when something causes an invalidation -
for example, if an element's contents change or it moves to a new location.
 If the page is static and the user is not interacting with the page then
the browser will happily do nothing until the next invalidation arrives.
 This means that if the requestAnimationFrame callbacks were only invoked
when the browser needed to repaint, it wouldn't be possible to drive an
imperative animation from requestAnimationFrame callbacks alone - they would
simply not fire unless something else triggered a repaint and the animation
would not be smooth.

I don't have any alternate text ready to propose at this time.  My personal
preference would be to phrase the charter text more directly in terms of the
problems we are trying to solve - for example, something about supporting
animations efficiently.

- James