[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 <firstname.lastname@example.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 :
> 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.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: