On Tue, Nov 30, 2010 at 9:42 AM, Benoit Jacob <firstname.lastname@example.org>
I agree that this is hard, but if the choice is between the browsers and the web applications, it seems clear to me that it's best to let the browsers handle that, as that will enable much better collaboration, for these reasons:
----- Original Message -----
> >> Steve explained in an earlier email how ACCELERATION_STATUS may not
> >> be
> >> very useful,
> > Right, I should have read his email more carefully the first time,
> > I've
> > replied to it now. I claim that his particular example is best
> > handled by
> > the WebGL implementation.
> So who will be the organization that pro-actively looks for problems
> the faked vertex-texture support - for EVERY graphics card, every
> CellPhone...with EVERY driver version on EVERY OS and in EVERY browser
> and decides which to fix and which not to fix...and to do this in a
1. there are far fewer browser makers than there are web applications
2. there is good cross-browser collaboration around WebGL already
3. some major browser engines supporting WebGL are open source, further easing collaboration
4. browsers compete against each other to run faster a given web application, so you can trust us to take seriously bugs like "your browser is 2x slower than the competition on this game".
5. browser makers receive plenty of bug reports already (at least Mozilla does), anyway, about a given WebGl app not working on a given graphics card, or being very slow. So we have to handle this stuff anyway.
>Browsers update themselves rather frequently anyway (security fixes...). Frequently enough for this use case.
> That's an immense on-going task requiring a lot of funding.
> What's more, when you do find a problem, how will you ensure that
> end-user gets a browser update?
I understand, but as far as I can see, having to wait for a month for an issue to be fixed in browsers and an update to be deployed is not too bad, especially if you consider that in exchange for that, you get to benefit from fixes found in other web apps too.
> When an application author finds a bug with a particular setup - he
> probably work around it right then and there and have a new web page
> within hours...but only if he can make the fix happen apply only to
> particular setup.
But this is precisely what is entirely unacceptable to developers. Imagine the following not too unreasonable situation:
In the year 2015, all browsers, even IE 12, have WebGL support. Browsers and computers are fast enough to run today's quality of client side apps in the browser. As a result, Blizzard releases StarCraft 3 as a web app using WebGL, to a user base of a hundred million.
Shortly after launch they discover that a particular graphics card combined with a particular browser not only doesn't work well, but causes the graphics card to freeze up and crash the entire computer on 0.1% of the user base.
Obviously this is a high priority issue to be fixed, so the web browser maker will look into it and fix it within a week or two, and the new browser version will make it to users in a month or two.
This leaves StarCraft 3 crashing computers of 100k users for over a month. In contrast, if Blizzard can identify that this always happens with a particular graphics card and browser, they can stop the crash immediately in minutes replacing it with an error message, and get to work on finding a workaround for that particular graphics card. It maybe takes them a day to find a solution that though unideal allows the game to run in a slightly degraded fashion.
The result for them is 100k users being able to play StarCraft 3 for 30 days versus crashing their computers for 31 days (and potentially having them not return to the game ever).
Put another way, assume they charge $15 a month like for World of WarCraft. Not giving Blizzard the renderer string could cost them $1.5 million or more in this situation.
This may seem a bit far fetched, but if you want WebGL to catch on, you have to let it catch on big in situations like this, and being able to immediately release patches for specific users is important.
With the first solution that I proposed, getParameter(VERTEX_TEXTURE_IMAGE_UNITS) would return 0 on said hardware, so you would be able to handle that.
> But worse still - to extend the vertex-texture example further:
That's why I proposed my alternative proposal: keep default behavior unchanged, introduce a new hint() parameter or context attribute DONT_WANT_SLOW_FALLBACKS switching to above-described behavior.
> But the other guy would find that disasterous - he'd much prefer for
> WebGL to do nothing at all.
You are currently subscribed to email@example.com
To unsubscribe, send an email to firstname.lastname@example.org
the following command in the body of your email: