[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Delay display of WebGL?
- To: stephen white <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Delay display of WebGL?
- From: Steve Baker <email@example.com>
- Date: Sun, 14 Nov 2010 09:42:55 -0600
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=ede2l 9WgrqwA5/a0wF5Ya5AEExY=; b=ZywhVq2KteHdGKaW/udwEJUedH9vlcm9+J+sN JdqDBdNI0loKkFm9DJA0wV5KECb2b4jbxC8POIM6dYz22oYkmC3462MKcbEmAVkw uEd5HEq1ZOdA8Ad4ak8zR8iJbAH6gCbltAY0MfGamHk0Yyga2Bw/8REgWSFbzVEF EjW5kc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=KDxcL1p4pFlOpT8q/vd+RaGaiCvLBEa5U4fcklda4rqNBC4uShWR5pFg4Joow U5PdEnGzfUqJNRnGgFeImWvsWMHbn3Kc5V/Z1CoVrv2uHtZh2RnFR4IXn6X7PAl+ D928WOpiJJATmSpa2dOzHpA1i7gaKFesTfnnHPvEJ8FR34=
- In-reply-to: <A0CA3A3D-D139-4E92-9F6D-D6E0236A4B14@adam.com.au>
- References: <A0CA3A3D-D139-4E92-9F6D-D6E0236A4B14@adam.com.au>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
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.
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.
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?
> 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: