So.. I wound up speaking to Robert offline and in our discussion his comments became much clearer to me and I think that it's at least worth documenting in case anyone else misunderstands as I did (even historically via the archive).
There are really a few proposals here which are sort of only tangentially related in that they all happen to deal with time and visibility in the current ways of coding. I think that it would be a mistake to assume that they are necessarily inherently related in designing a new API without at least considering that they might be different things. The first has to do with the fact that timers are currently used for animation which has the effect of wastefully eating CPU cycles to do things that the OS won't ultimately respect anyway (i.e. calculate visual updates for something that is non-visible). What Robert has suggested specifically is that there be an API specifically "about" animation which allows the user agent to essentially publish a universal "next frame" kind of event that animations subscribe to. There are at least two practical side effects to this - one of which is the thing being discussed here... That user agents _could_ (if they choose) optimize this universally with techniques like avoiding the "paint" part if the window is minimized. The second practical benefit is that the API expresses much more clearly what it is about and is less shoe-horned into what just happens to be the way we've gotten it to work with the existing technologies -- no more need to create timers or set frame rates, worry about interleaving frames, etc -- that would all be handled quite beautifully by the simplicity of the API design. The second - and seemingly only partially related topic is whether the windows state or visibility should be accessible in script... It is this second question to which my questions are directed. I definitely see a potential utility there, but without well defined answers to some of those questions - it seems that you could easily create a real rats nest of complexity, incompatibility and unexpected side-effects. On Tue, Oct 20, 2009 at 8:48 PM, Brian Kardell <bkard...@gmail.com> wrote: > I suppose I should not have used that phrasing... It wasn't really > accurate and it obscures my point... My point was that I actually > wanted it to run in the background... So - does time stop, or just > rendering? I think that you have to be very clear. > > > > On Tue, Oct 20, 2009 at 8:43 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: >> On Wed, Oct 21, 2009 at 4:34 PM, Brian Kardell <bkard...@gmail.com> wrote: >>> >>> For example, I recently the Image Evolution demo from >>> http://www.canvasdemos.com/2009/07/15/image-evolution/ as a kind of a >>> performance test and let it run for three days - during which it was >>> not "visible" 99.999% of the time. Should processing stop - or just >>> painting? Painting wont happen because the OS says it wont right? >> >> Depends on the OS, I guess. Performance testing is hard; for good >> performance testing you need a carefully set up environment. It's OK to >> require special browser configuration to make it believe that the user is >> always present and the window is always visible. I don't think we need to >> avoid Web platform or browser features because they might make performance >> testing a bit harder. >> >> 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] >> >