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?


From: [] On 
Behalf Of Robert O'Callahan
Sent: Monday, October 19, 2009 2:52 PM
Subject: Re: solving the CPU usage issue for non-visible pages

I have a proposal for solving this here:

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.

"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]

Reply via email to