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

Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings



That was completely against my point. I did acknowledge in my scenario that it would be high priority and the browser maker would likely fix it, and the ideal solution would be all well and good with everyone holding hands and singing.

The issue is that Blizzard can't wait for you to fix that. They could push out a temporary stop in minutes and a workaround in hours, while the best case for browsers is automatically upgrading in the background so a workaround could be pushed the next time you restart your browser.

On Linux at least, I have seen graphics card issues that take down X, which is effectively as good as crashing the computer for many desktop users (all programs you had open quit, desktop users don't care much about servers).

The point was not about whose job it is to fix it, but about the possible latency in fixes and the user, financial, etc impact of that. Even if you come up with a way to push fixes to Firefox in hours, that doesn't help IE users, and Blizzard may care deeply about IE users who pay the bills.

-Brian

On Tue, Nov 30, 2010 at 10:59 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
> 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.

First of all, in my experience, graphics drivers crashes hit by WebGL almost never take down the entire computer. I'm not even sure that has happened once. What does happen is that it will take the process down. In multi-process browsers like chrome, it will then not even crash the entire browser.

To put this into perspective, we have very precise data about graphics driver crashes at Mozilla [*], whenever they occur we almost always receive a crash report, we mine them, so we have data to say rather confidently that they're under control. We've always been able to either work around them or blacklist a given driver version, and we forward the crash reports to graphics cards manufacturers. So the situation is looking quite good already today, and it's only improving, so I don't see it being a problem in 2015 to the point that web apps would have to worry about it themselves.

Also, WebGL is not the only thing in currently developed browsers that uses the graphics cards directly and is exposed to graphics driver crashes. WebGL currently accounts for a small minority of our graphics crashes.

[*] for example, here's a search for NVIDIA crashes last week:
http://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&branch=2.0&range_value=1&range_unit=weeks&date=&query_search=signature&query_type=startswith&query=nv&build_id=&process_type=browser&hang_type=any&do_query=1

Cheers,
Benoit

>
>
> 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.
>
>
> -Brian
>
>
>
>
> >
> > But worse still - to extend the vertex-texture example further:
>
>
> 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 the other guy would find that disasterous - he'd much prefer for
> > WebGL to do nothing at all.
>
> 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.
>
> Cheers,
> Benoit
>
>
>
> -----------------------------------------------------------
> 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: