[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture
Totally fine by me. I was actually under the impression that a lot of graphics APIs don't support this for the reason that depth buffer layouts are sometimes secret driver territory and/or paired with hierarchy info.
On Thu, May 17, 2012 at 4:50 PM, Kenneth Russell <firstname.lastname@example.org>
It looks like there may be some difficulty supporting the OES_depth_texture extension in its current form in the ANGLE emulation library. In short, uploading of depth information from the CPU during TexImage2D and TexSubImage2D may be difficult. (The issues actually occur because of interactions between OES_depth_texture and OES_packed_depth_stencil, both of which ANGLE supports, but right now it doesn't look like it's possible to guarantee future support for uploading data to depth textures.)
To make cross-platform support more feasible, we would like to impose a restriction in WebGL's exposure of OES_depth_texture that, when calling TexImage2D for DEPTH_COMPONENT textures, the only ArrayBufferView argument supported is NULL.
These textures could still be rendered to and sampled from; these are the most common use cases.
Some implications of this restriction would be:
- It wouldn't be legal to call texSubImage2D for these textures.
- It wouldn't be legal to call the texImage2D entry points taking DOM elements and ImageData for these textures.
Any comments or concerns about imposing these restrictions? Any objections to making the change in-place to http://www.khronos.org/registry/webgl/extensions/OES_depth_texture/
? A separate WEBGL_depth_texture extension could be defined instead, but I think it would be confusing to have two copies of similar extensions, only one of which is actually implementable everywhere. If it turns out in the future that ANGLE can fully support OES_depth_texture, the restriction could be removed and any associated conformance tests updated.