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

Re: [Public WebGL] Depth+stencil extension

On Sat, Apr 3, 2010 at 7:54 AM, Chris Marrin <cmarrin@apple.com> wrote:
> On Apr 2, 2010, at 12:01 PM, Kenneth Russell wrote:
> ...
> And I  think that's much too harsh. We should somehow fail gracefully when
> an attempt is made to create and unsupported combination of depth and
> stencil. If this is not OpenGL ES spec compliant then we should describe
> thoroughly how the behavior differs and make sure it returns enough
> information to the authors so they can understand how to proceed. I don't
> think the fact that it's not possible to create an FBO with both a depth and
> stencil buffer should prevent ANY WebGL from running.
> I agree with you that it would be better to run at least some WebGL
> content on such devices rather than none.
> After rereading the section in the OpenGL ES 2.0 spec on framebuffer
> objects and completeness, it sounds like from a strict standpoint, if
> an OpenGL ES 2.0 implementation supports just a color renderbuffer or
> texture FBO attachment (and no other attachments, for example depth or
> stencil), then it is allowed to return FRAMEBUFFER_UNSUPPORTED from
> CheckFramebufferStatus() for any other configurations.
> Is that correct? Mark Callow or others from the ES working group, is
> this legal (if poor) behavior?
> Basically, the question is whether the majority of ES 2.0
> implementations today support all of the FBO attachment combinations
> color, color+depth, color+stencil, and color+depth+stencil. If they
> don't, then there is basically no issue. If they do, then we should
> specifically mention in the Differences section of the WebGL spec that
> WebGL implementations may have less support of certain framebuffer
> attachment combinations than is implied by the OpenGL ES 2.0
> specification.
> I think it's clear that the OpenGL ES 2.0 spec makes it legal to create and
> FBO with color+depth or color+stencil. The question is about
> color+depth+stencil. As you've stated before it's not reasonable to let an
> author attach both a stencil and depth buffer and then try to "figure out"
> intent in the implementation a do the right thing. But that's why you
> added DEPTH_STENCIL_ATTACHMENT right? Section 6.2 makes it pretty clear how
> to do depth+stencil.
> So I think we're covered as far as how to do it. It should also be clear
> that attempting to do depth+stencil on a platform that can't do it in any
> way will fail.  It seems reasonable that this failure come either when
> attaching depth+stencil or in the CheckFramebufferStatus call. The only
> question is whether we fail at context creation time if the platform can't
> handle depth+stencil. I don't think it should, but I believe it is (at least
> in WebKit) today.

Let me be clear: if a desktop OpenGL implementation does not support
EXT_packed_depth_stencil then we *will not* be able to support *any*
stencil FBO attachments in WebGL. We will not be able to support the
combination color+stencil, let alone color+depth+stencil, because as
far as I know, individual stencil attachments (even if there is no
depth attachment) are very poorly supported on desktop OpenGL.

If anyone has data to counter this assumption, please post.

The primary question is whether we think it is acceptable to fail to
attach both stencil and depth+stencil attachments to FBOs in a
compliant WebGL implementation.


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: