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

Re: [Public WebGL] Delay display of WebGL?



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: