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

Re: [Public WebGL] Depth+stencil extension

On Apr 3, 2010, at 11:35 PM, Kenneth Russell wrote:

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

What you're saying is that any OpenGL implementation that doesn't support EXT_packed_depth_stencil doesn't support the definition of a stencil buffer in an FBO at all. I find that hard to believe. I can imagine that an implementation that supports EXT_packed_depth_stencil can ONLY do a stencil buffer packed. And I can imagine that SOME implementations that don't support EXT_packed_depth_stencil don't support stencil buffers in FBO's at all. But for those I would imagine that they have some alternative way of doing off-screen buffers with stencil (like pbuffers).

I'd really like to hear from hardware vendors about this. If the FBO implementations are as spotty as you say, we have a real problem with supporting FBO's at all, don't we?


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: