[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 <firstname.lastname@example.org> hat geschrieben:
>On 11/14/2010 10:08 AM, Cedric Vivier wrote:
>> On Sun, Nov 14, 2010 at 23:42, Steve Baker <email@example.com> 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 :
>> 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 :
>> (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>?
>might need this capability. WebGL just makes for much heavier apps
>that make the need more obvious/urgent.
> -- Stee
>You are currently subscribed to firstname.lastname@example.org.
>To unsubscribe, send an email to email@example.com with
>the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: