[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL extension registry
- To: Steve Baker <email@example.com>
- Subject: Re: [Public WebGL] WebGL extension registry
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Mon, 6 Dec 2010 16:43:38 -0800
- Cc: email@example.com
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291682620; bh=k6oHvlm6lZI8BQs1uU+wcM/u8f8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=imsZAq2CB+73RnJMRZXRQdIWgdukFmNR2CPWUxHKMNCOO9netzO9VcxqWNvu5EAvo JaOSoWJgByiWIkbLRmOqg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LCTrBQnYe4O7hfm+hNBCMfJw5sOxDnAcDk8XHxVj88Q=; b=BqKaGEOyJcw4h0T/ZJVulhkyNuC73j1X96FDdZCgTGgHLh5o76hcrZpbp/lKICjxlM uWnv4egQq34LrKGwCAMw==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JZP+lz9FI2b7r1UQVYp9fyhUvLyo6y3DvBtiFWKlFF6hkfl2tZR0mmaTERkp4cA4Rp meyRyi3jjNZmOvdlUyDA==
- In-reply-to: <4CFD8363.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTi=Fs1_d54LHFtkeZtcxyCYVb1uO8nFFmefhDhkn@mail.gmail.com> <4CFD8363.email@example.com>
- Sender: firstname.lastname@example.org
On Mon, Dec 6, 2010 at 4:44 PM, Steve Baker <email@example.com> wrote:
> Damn! And I'd *just* finished writing my shadow code! :-)
> I think this is a great thing - but it's a bit of a change in direction
> isn't it? I thought the plan was to have no extensions in v1.0 ?
No. The concern was over whether these extensions would be *part of*
the 1.0 spec. Separating them into their own registry resolved that
> Also, doesn't this open up the whole lack-of-anonymity can-of-worms again?
Perhaps, but there are always cost/benefit tradeoffs. In this case, I
think the availability of floating-point textures as a WebGL extension
is so incredibly useful that it dwarfs any concerns over exposing one
more bit of information that could be used to identify individuals.
(Also, floating-point textures are likely to be supported on all
hardware supporting WebGL, so this extension's availability is very
unlikely to expose additional information.)
Note though that this is an extension, so you'll still need a fallback
path if you expect your code to run on a WebGL implementation that
doesn't support it.
> -- Steve
> On 12/06/2010 12:45 PM, Kenneth Russell wrote:
>> The WebGL working group is pleased to announce the availability of the
>> WebGL extension registry. The preliminary URL is:
>> This URL is likely to change in the coming weeks. A link to the
>> registry has been added to the references section of the
>> specification, and that link will be kept up to date.
>> OES_texture_float is close to being implemented in WebKit, and we'll
>> post to the list once it is.
>> Specifications for a few more extensions (OES_depth24,
>> OES_standard_derivatives, ...) are planned; see comments in the HTML
>> for the extension registry.
>> 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:
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: