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

Re: [Public WebGL] OES_depth24



Proposing to reject OES_depth24, reason noted in the change revision: https://github.com/KhronosGroup/WebGL/pull/851

Last chance for anybody to object to canning this one.

On Wed, Feb 4, 2015 at 8:38 PM, Kenneth Russell <kbr@google.com> wrote:
I think this is a reasonable workaround and would prefer to reject
OES_depth24 to keep ourselves focused.


On Wed, Feb 4, 2015 at 11:32 AM, Florian Bösch <pyalot@gmail.com> wrote:
> Excellent, thank you. So is there consensus that guaranteed 24-bit depth
> precision can be achieved with a depth texture and that is a suitable
> alternative to a 24-bit renderbuffer?
>
> On Wed, Feb 4, 2015 at 8:17 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> OK, merged mainly to move it to the rejected state for documentation
>> purposes.
>>
>>
>> On Wed, Feb 4, 2015 at 6:51 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> > Ken, if you could merge the proposal we can talk about moving it to
>> > rejected.
>> >
>> > On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell <kbr@google.com> wrote:
>> >>
>> >> The
>> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/
>> >> extension already allows applications to allocate framebuffer objects
>> >> with a depth-texture attachment having 24 bits of precision. How
>> >> urgent is it to support renderbuffers with the analogous format?
>> >>
>> >> We're focused on getting WebGL 2.0 prototypes and conformance tests
>> >> out the door and I think that exposing this extension will be a
>> >> distraction. Adding a new extension to WebGL implementations is a
>> >> non-trivial exercise due to the large number of platforms and browsers
>> >> involved.
>> >>
>> >> -Ken
>> >>
>> >>
>> >>
>> >> On Mon, Jan 26, 2015 at 1:38 PM, Florian Bösch <pyalot@gmail.com>
>> >> wrote:
>> >> > I propose to add the extension OES_depth24 to WebGL for these
>> >> > reasons:
>> >> >
>> >> > It's really the companion extension to depth textures since they
>> >> > enjoy
>> >> > about
>> >> > the same level of support (and depth textures support 24-bit depths)
>> >> > The frontbuffer on WebGL is already almost always 24-bit
>> >> > Framebuffer objects can only choose a 16-bit depth renderbuffer (and
>> >> > so
>> >> > are
>> >> > at a disadvantage)
>> >> > It is well supported on mobiles (around 92%)
>> >> > It has been core functionality on desktops since OpenGL 3.1
>> >> > It's defined on desktops since ARB_framebuffer_object (which is a
>> >> > prerequisite to FBOs)
>> >> > It's supported by Direct3D 9 (D24X8)
>> >> > Considerable time will pass until WebGL 2.0 can be as widely
>> >> > supported.
>> >> >
>> >> > A pull request has been prepared for review:
>> >> > https://github.com/KhronosGroup/WebGL/pull/831
>> >
>> >
>
>