Re: solving the CPU usage issue for non-visible pages

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 <bkardell@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 <robert@ocallahan.org> wrote:
>> On Wed, Oct 21, 2009 at 4:34 PM, Brian Kardell <bkardell@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]
>>
>

Received on Wednesday, 21 October 2009 12:21:30 UTC