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

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

> I think I won't write to any firefox list for now, instead I'll just say
> as I wrote in a previous email and wait for, say, 1 year to see if webgl
> apps are actually using the RENDERER/VERSION strings (since WebKit is
> giving this information). In 1 year, we'll have more concrete information
> to base decisions on, and it'll still be time to get things right for 2015
> ;-)

But a year is plenty enough for potential big-time users of WebGL to write
it off as useless - I don't think we can just shrug this decision off.

Aside from anything else, waiting to see what'll happen isn't going to
work because not doing it affects how developers behave.  If Firefox
doesn't support identifying the setup using VENDOR/RENDERER/VERSION then
people won't use that even if it's available in other browsers - simply
because Firefox has such a large market share.  They'll be forced to go
the horrible route of doing bunch of much uglier hacks (such as calling
every glGet in sight and comparing it against some database of card types)
- and having written that, they'll use it on the other browsers
too...simply because it guarantees consistency across browsers and it
saves implementing both mechanisms.

I'm pretty sure we don't want the "call every glGet in sight and compare"
approach.  It has all of the problems of information leakage that reading
RENDERER/VERSION has - but it's ugly, flakey and hard to for developers to

Even if people did decide to use the feature in Chrome but not in Firefox
- we'd be faced with a bunch of people saying "Such-and-such game looks
great in Chrome - sadly it's unplayable in Firefox".  Do you REALLY want
that?  Chromes' market share is growing - and cool 3D games are just the
kind of killer app that could push Chrome into first place and Firefox
into oblivion.

I don't think we can responsibly duck this decision.

What these strings return needs to be firmly defined in the WebGL

If they are going to be meaningless - we should remove them from the
specification completely.  If they are going to mean something then we
need to say what they mean and everyone should implement that.

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