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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture





----- Original Message -----
> 
> 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
> registry.

No objection from me, this sounds like the right approach here.

Benoit

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

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