[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- To: public webgl <email@example.com>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: Tim Johansson <firstname.lastname@example.org>
- Date: Wed, 01 Dec 2010 10:30:41 +0100
- In-reply-to: <AANLkTi=Tyya3u3sauV8fnMenqV5meJj6QjmjcZ5pAyU3@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4CF3CC6A.email@example.com> <1472832008.435493.1291047599809.JavaMail.firstname.lastname@example.org> <AANLkTi=Tyya3u3sauV8fnMenqV5meJj6QjmjcZ5pAyU3@mail.gmail.com>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:184.108.40.206) Gecko/20101027 Thunderbird/3.1.6
On 2010-11-30 05:24, David Sheets wrote:
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.
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.
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
(so the application can work around bugs)
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
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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: