[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: Re: [Public WebGL] Delay display of WebGL?

I think window.onfocus and window.onblur tell you whether the tab is active or not - that should be sufficient for most current situations.


Steve Baker <steve@sjbaker.org> hat geschrieben:

>On 11/14/2010 10:08 AM, Cedric Vivier wrote:
>> On Sun, Nov 14, 2010 at 23:42, Steve Baker <steve@sjbaker.org> wrote:
>>> If not, then perhaps there is a case for adding a new timer event that
>>> only triggers when the tab is visible.   Then application writers could
>>> use that event to trigger their draw() calls - and trigger the normal
>>> timer event for critical operations that don't generate graphics.
>> Yes, we discussed this at length few months ago :
>> http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00057.html
>> Unfortunately nothing much came out of it iirc (?)... but there is
>> efforts outside of WebGL to add some kind of generic event that
>> triggers before frame rendering (mozOnBeforePaint? Vlad?)
>> IMHO adding another timer is more of a workaround than a long-term
>> solution, as it 'promotes' developing an app for a particular
>> framerate - something hard to do when the content can run on anything
>> from cellphones to high-end desktops.. so some problems would not be
>> fixed by this.
>> An API that promotes framerate-independence on the other hand would
>> solve most if not all the problems you pointed out, eg :
>> http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00068.html
>> (which ultimately should be what a "onBeforePaint" event would do -
>> question is do we need something WebGL-pecific, I guess not)
>Hmmm - tricky.
>We also need to look ahead to more powerful machines than we have right
>now...and correspondingly more sophisticated uses.
>In many games, the physics software needs to run at a fairly uniform
>frame rate that may be higher than the graphics rate. 
>Framerate-independent physics is a tough sell - the core mathematics
>really isn't there yet - and physics is increasingly likely to use the
>GPU in CUDA-like ways.  Networked applications may also place
>constraints on minimum update rates because of the need to time-out when
>the user navigates away from the page.
>There are other ikky issues relating to tabbed browsing:  Suppose the
>app is using the camera and microphone via this new "rainbow" stuff? 
>Can it/should it still be able to do that when the tab is hidden?
>IMHO, we need to let the app decide what it needs to run on a regular
>update basis - and what can be slowed down on slow hardware or halted
>altogether when the system doesn't have the user's attention (eg because
>it's in a background tab or (perhaps) hidden behind some other window -
>or because the screen/power-saver has kicked in).
>At a minimum, it would be nice if there were some query an application
>could make to ask if it's currently visible or not.  Maybe a DOM thing
>you could read on the <body>?
>But I agree that this is not a WebGL issue - any JavaScript application
>might need this capability.   WebGL just makes for much heavier apps
>that make the need more obvious/urgent.
>  -- Stee
>You are currently subscribed to public_webgl@khronos.org.
>To unsubscribe, send an email to majordomo@khronos.org with
>the following command in the body of your email:

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: