[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Depth+stencil extension
On Apr 1, 2010, at 5:04 PM, Kenneth Russell wrote:
> On Thu, Apr 1, 2010 at 4:41 PM, Chris Marrin <firstname.lastname@example.org> wrote:
>> So we believe the problem with failing tests on the WebKit build bots has to do with the fact that many are headless servers and are therefore using the software OpenGL driver, which does not support the depth+stencil extension.
>> This makes me think that we should only fail to create a context on such systems when they actually ask for both a depth and stencil buffer. That will allow most tests to continue to run on headless systems and will allow us to carefully segregate tests that use both so they can be skipped when we detect that the test machine does not support it.
>> This raises the question of letting the author know about such situations. Is there a way today that an author can know that the reason a context was not created was because it has depth+stencil? I hope we don't force authors to first try depth+stencil and then depth only just in case that's why it failed.
> The problem isn't with the creation of the WebGL back buffer; we can
> always ignore the request for a stencil buffer and still be spec
> compliant. The issue is that WebGL (and OpenGL ES 2.0) require that
> client code be able to create a framebuffer object (FBO) and attach
> both depth and stencil renderbuffers. FBO support isn't optional in
> WebGL or OpenGL ES 2.0.
> On desktop GL, to the best of my knowledge, using the
> EXT_packed_depth_stencil extension is the only widely supported way of
> attaching both depth and stencil renderbuffers to an FBO. If this
> extension isn't available, then if user code happens to use
> framebuffers and try to create a depth+stencil renderbuffer, the call
> will fail with an OpenGL error. I don't think this is an acceptable
> failure mode. If we return a non-null context from
> getContext("webgl"), then it needs to support all of the core
> functionality. Therefore unfortunately, if we're running on desktop
> OpenGL and EXT_packed_depth_stencil isn't available, I think we need
> to refuse to run any WebGL content.
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.
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: