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

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



On 2010-11-30 05:24, David Sheets wrote:

For application authors, there is immense value to be had from being
able to determine which card and drivers the user has - both at run
time
(so the application can work around bugs)
It seems to me that we can realistically aim for good enough WebGL implementations that this shouldn't be needed. I would be very interested in the list of graphics-card-specific things that you need to do on Minefield, I would try to handle these as bugs in our implementation.
With at least 4 parties (webdev, browser vendor, card driver vendor,
operating system) involved in providing a seamless 3-d web experience,
there will always be bugs and incompatibilities. Yes, the WebGL
implementation is the critical multi-platform abstraction that should
hide these issues but limiting the information available to
application developers is the wrong place to enforce the abstraction
for pragmatic reasons. Well-written applications won't use card
sniffing unless absolutely necessary. Card sniffing has a clear
portability downside that most web devs are aware of because of user
agent sniffing.

I really doubt most web developers are aware of the portability issues. For user agent strings there are many sites which just does not work in Opera if the user agent says "Opera". The "solution" to this is to fake the user agent string and mask as firefox or IE. Masking as one of those quite often makes the site work perfectly.

I can see why it is useful to many devs to know the renderer strings, but there is a high risk that we'll get into the same problem as with user agent strings and have to add some kind of renderer string spoofing to make content run on less common graphics cards. Then we have gained nothing at all since you cannot trust the strings.

//Tim

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