- From: James Robinson <jamesr@google.com>
- Date: Tue, 15 Mar 2011 15:21:40 -0700
- To: public-web-perf@w3.org
- Message-ID: <AANLkTik9qBpBnaMWMv+BNi=1vuL+3qJzMmvxyToiPjxt@mail.gmail.com>
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
Received on Tuesday, 15 March 2011 22:22:10 UTC