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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture

On Fri, Jun 1, 2012 at 4:42 PM, Gregg Tavares (社用) <gman@google.com> wrote:
> On Thu, May 17, 2012 at 6:53 PM, Ben Vanik <benvanik@google.com> wrote:
>> As a developer having to deal with extensions, I'd prefer that the browser
>> vendors pick a behavior and stick with that for awhile. If no major use
>> cases can be thought of for the missing functionality when running under
>> ANGLE, I'd much rather have only that one extension to check
>> for/query/handle in my tool chain. If both were exposed right now it'd
>> essentially be fragmenting on platform (browsers with ANGLE, aka Windows,
>> vs. those without, aka everything else), and that's annoying.
>> On Thu, May 17, 2012 at 6:20 PM, Mark Callow <callow_mark@hicorp.co.jp>
>> wrote:
>>> On 18/05/2012 06:58, Brandon Jones wrote:
>>>  I can see the confused Stack Overflow posts already if there were two
>>> nearly-identical extensions...
>>> As opposed to confusion caused by having 2 nearly identical extensions
>>> sharing the same name?
>>> I think the names should be different so that implementations not using
>>> Angle can expose the real OES_depth_texture extension.
>>> Regards
>>>     -Mark
> I propose we make a new extension ANGLE_depth_texture or WEBGL_depth_texture
> and deprecate the old one OES_depth_texture.  We can add OES_depth_texture
> back if and when it actually is compatible with the real OES_depth_texture
> and most browser has a path to get there.
> Given that ANGLE has, up until now, not supported this and given that AFAICT
> no browsers have exposed OES_depth_texture there's no reason not to change
> it.  OES_depth_texture arguably has a specific meaning. If we keep the name
> OES_depth_texture then searching for it will bring up the OpenGL ES
> specification which will be confusing for developers if WebGL's
> implementation is different.

Good point that it may cause developer confusion if WebGL's exposure
of OES_depth_texture imposes additional restrictions.

What if instead of deprecating WebGL's OES_depth_texture extension, we
simply rename it to WEBGL_depth_texture, and impose the restrictions
in http://angleproject.googlecode.com/svn/trunk/extensions/ANGLE_depth_texture.txt
? Rationale: no browser has yet exposed the OES_depth_texture
extension to WebGL, so there's no risk of breaking code; and if it
turns out that the restrictions can be lifted, it's conceptually
correct for WEBGL_depth_texture to be changed to expose exactly the
functionality from GL_OES_depth_texture.

Are there any objections to taking this approach? If not, I'll rename
OES_depth_texture to WEBGL_depth_texture in the WebGL extension


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