This looks like a nice solution to the animation case. Should we also consider the case where a web site wants to keep its interface up to date with some server state and is using up CPU time and network resource to do so?
E.g. I might have Google Wave open in a background window, viewing a document that is being rapidly updated by other users. If the window is minimized then I can’t see the window, and so there is little point consuming network, CPU, and power resources maintaining an interface that I’m not looking at. This is similar to the animation case in that we have a page that is being updated unnecessarily, but it is also sufficiently different that it may want a different solution. I’m thinking perhaps we want some kind of API that basically says: “deliver me messages from this server event source, but only if I’m visible” Any thoughts? -Rob From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Robert O'Callahan Sent: Monday, October 19, 2009 2:52 PM To: public-webapps@w3.org Subject: Re: solving the CPU usage issue for non-visible pages I have a proposal for solving this here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bf The gist is very simple: 1) window.requestAnimationFrame(): Signals that an animation is in progress, and requests that the browser schedule a repaint of the window for the next animation frame, if the window is visible. 2) The browser fires a beforePaint event at the document root element (bubbling to document and window) any time it repaints the window. This event contains a 'displayTime' field containing a Javascript Date object representing the time at which this frame is likely to become visible to the user. Animation scripts should register an event handler that updates the DOM/CSS state to show that point in the animation. If the animation has not ended, the event handler should call window.requestAnimationFrame() again to ensure another frame will be scheduled in a timely manner. This gives the browser control over the frame rate, lets it suppress animation in non-visible windows, lets multiple animations play in synchrony, and should be easy to retrofit into code that's currently based on setInterval. I think it can also work well with architectures that do compositing in a dedicated thread or process. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
