[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- To: "Benoit Jacob" <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: email@example.com
- Date: Tue, 30 Nov 2010 09:25:41 -0800
- Cc: "Thatcher Ulrich" <firstname.lastname@example.org>, email@example.com, "David Sheets" <firstname.lastname@example.org>, "public webgl" <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; s=sjbaker.org; bh=vydS6 sbcTzQFXV5bUxq80LPQRIk=; b=IU+a8g3yAZb/i2TdTXACAonA5nVfh0JphYeu4 arvPngiIML4ukwcmM/Ienadkl47RTTtJDjVeR5J3Wuo54TzuVs3DbqrNZ2D5kN60 H1Wne7N4Hl0wvAsXrqUfWkYxnv+YzI8ScVgcHGuhOgM/Hj0/s4GZGUzxyxd4ioYH FO3Re0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=BvqE/qIoze38tLTwaSgejB2chV7wLZ6sOtCUT9oDtwIkewPCSqBG8qRy2dce8 DaFLzT6l9z2l9HMKtpdEtkTMbXG1l/yQf4NsDxUeo87mwFmX8v+k/YYxX1JreYKk X8Mn5lxJdb5PfQSUYhVfMYiqy0ye/ewulcQUiGBP5gYcU0=
- In-reply-to: <1263187777.445343.1291135121732.JavaMail.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1263187777.445343.1291135121732.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
- User-agent: SquirrelMail/1.4.21
>> Steve explained in an earlier email how ACCELERATION_STATUS may not be
>> very useful,
> Right, I should have read his email more carefully the first time, I've
> replied to it now. I claim that his particular example is best handled by
> the WebGL implementation.
So who will be the organization that pro-actively looks for problems like
the faked vertex-texture support - for EVERY graphics card, every
CellPhone...with EVERY driver version on EVERY OS and in EVERY browser -
and decides which to fix and which not to fix...and to do this in a timely
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?
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
But worse still - to extend the vertex-texture example further:
* In my application, I have GIGANTIC vertex shaders - they do a ton of
heavy work - pushing them into CPU-software is a disaster.
* In some other application, there might be a tiny vertex shader that
reads the vertex texture and does almost nothing else. Even though
shaders are dumped into CPU-side software when we use a vertex texture,
In my case, the internal-to-WebGL fix would be to intercept the glGet that
queries the number of available vertex textures - and return zero instead
But the other guy would find that disasterous - he'd much prefer for WebGL
to do nothing at all.
So which does the WebGL fixing-graphics-hardware-bugs organization decide
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: