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

Re: [Public WebGL] Delay display of WebGL?



I'm sure the problem is "real".  My WebGL game brings the rest of the
system to a crawl on my netbook (the crappy Intel graphics chip runs
vertex shaders in CPU software!) - and it's a pain that you can't hide
it behind another tab to "pause" it while you get on with something else.

I added a "PAUSE" button to the game - but it would certainly be useful
to be able to automatically pause execution of the costly graphics bits
of a WebGL app when it's in an inactive tab.  But since WebGL might be
used in a lightweight manner in a page that would expect to continue
running when in a hidden tab - I don't think it would be wise for the
browser to prevent execution entirely.

Suppose the page is running an interactive multiplayer game - stopping
the script from running altogether would leave the server in a state
where it would be unable to tell whether the player had navigated away
altogether (ie "Game Over") or was merely doing some more important task
and had parked the game in a tab for a short time.

As another example - suppose some really complicated ray-tracing program
were using WebGL to show progress.  It might render one pixel per second
over hours.  On a fast machine, you'd certainly want to be able to open
other tab and get on with other work, checking back on your ray-tracer's
progress once in a while to see how it's getting on.  In an AJAX
environment, the application might need to grab data that's coming in
from the server even when it's in a hidden tab.

Since the browser can't distinguish these use-cases, I'd strongly oppose
a feature that automatically shut down execution when a WebGL page is
hidden.  It would have to be something that the app itself does voluntarily.

Is there some existing way for JavaScript to detect that the tab is
currently hidden?  That would be a spectacularly useful thing.  
Well-written apps could then continue to update only the non-graphical
parts of whatever they were doing and skip over the graphical update. 
You can't fix badly written apps like that - but there should at least
be a way for well-behaved apps to "do the right thing".

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.

As the browser starts to look more and more like a fully-fledged
operating system - things like task scheduling between tabs become more
and more important.

  -- Steve


On 11/14/2010 07:47 AM, stephen white wrote:
> When I'm clicking through my news feeds, I've noticed that my web browser gets busy and crashes as I reach the WebGL parts. Having a quick look shows that WebGL starts working immediately, so the demo pages are firing off before I've gotten around to looking at them.
>
> Flash delays until it becomes the front window, which is how I can open many tabs while not having a problem. Would it be worth doing the same for WebGL, as most WebGL demos tend to be fairly intensive as a way of demonstrating a new feature and how much it can do.
>
> Once again, I think my old machine is being a guinea pig as the demos are intended to run on GPU but some of them will run on my CPU instead. However I think the problem is real, and a quick fix now could help improve the initial reaction that people have to WebGL?
>
> --
>   steve@adam.com.au
>
>
>
> -----------------------------------------------------------
> 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: