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

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

> 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:
> 1. there are far fewer browser makers than there are web applications

But there are W OS versions, X graphics card types, Y driver revisions and
Z browsers.  The scale of the problem (if you attack it in WebGL) is

Application developers can handle it because they don't need to find and
fix every single driver bug - they only need to fix the one stupid one
that's getting in their way right now - and they can make informed
financial decisions as to whether that particular platform setup is common
enough amongst their demographic to warrant fixing.  We don't like having
to do that - but it's a fact of life.  If you're a startup games software
company with 10 employees, you have a near-zero chance of getting nVidia
or ATI to listen to you and fix a problem in their drivers - so working
around them has become second nature and an inevitable part of the
development cycle.

> 2. there is good cross-browser collaboration around WebGL already

Yes!  And I'm eternally thankful for that!  This mailing list is
absolutely invaluable.

> 3. some major browser engines supporting WebGL are open source, further
> easing collaboration

Yes - but I don't think you're going to let me go in (as an application
developer) and test for a particular card/driver combo and hack the
results coming from glGet as a result...and have the fix out in a week. 
There is just too much chance that my "fix" would disrupt someone else's

> 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".

True.  But will you respond to "your browser is 2x slower but only on some
minor free game on an nVidia 6100 with the 1.234a Linux driver in a 64 bit
environment" with quite such vigor?

These problems tend to be obscure - and there isn't any publicity value to
be found in fixing them.

> 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.

Well...maybe...but let's look at the track-record here.  There are some
amazingly serious bugs out there with (for example) the <audio> and
<video> tags that were reported back in 2008 and are still not fixed. 
What's to say that WebGL bugs won't suffer the same fate?  I'm not talking
about trivial bugs - take (for example) the inability to make a simple
HTML audio or video media element loop in Firefox, for example:

  Bug 449157 - Implement the looping attributes in media elements

...for those of us trying to implement sound effects in our games - this
is an exceedingly serious problem.

So I'm trying to get a game out the door for the new year - can I rely on
that bug being fixed by then?  I don't think so!  Can I ship without sound
effects?  Not really!  So I have to find a work-around...and I have...but
the work-around trips a different issue in Chrome (because of the way it
streams audio) - so I need two completely different code paths for looping
sound effects or else I can't use them in my game.

Fortunately, I can easily check whether I'm running in Chrome or Firefox
and now I have a somewhat acceptable workaround.   I only can do that at
the per-browser level...but if the bug is in the GPU or its driver I'm
completely helpless because WebGL is agressively trying to prevent me from
figuring out when to apply the fix.

>> 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
>> every
>> end-user gets a browser update?
> Browsers update themselves rather frequently anyway (security fixes...).
> Frequently enough for this use case.

...except for my two year old audio/video bug?

>> When an application author finds a bug with a particular setup - he
>> can
>> probably work around it right then and there and have a new web page
>> up
>> within hours...but only if he can make the fix happen apply only to
>> that
>> particular setup.
> 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.

A month would be pretty bad coming up to an Xmas release!  But it's not a
month.  We know from my example above that it can easily be two years -
and that's just in the particular case I've tripped over.  I bet you can
find fairly serious issues in the Bugzilla database going back much
further than that!

Also, these bugs are of a different nature.  The bugs you're used to
fixing are bugs of your own making.  Bugs that mostly have a clean fix. 
What we're talking about here are bugs in hardware and software that you
may never have seen - which you can't even buy anymore.  They are also
"grey area" things like the vertex texture issue that are bugs to some
people and perfectly reasonable built-in fallbacks to others. "Fixing"
them might be very controversial.

As an application developer, I can make compromises with my content and do
large-scale algorithmic workarounds - that's not always possible at the
WebGL level.

  -- Steve

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: