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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture



On Thu, May 17, 2012 at 10:50 PM, Kenneth Russell <kbr@google.com> wrote:
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.)
Do I understand it right that if you enable both packed depth stencil and depth_texture and then you'll get errors/garbage/something like that? I'd assume the same would be the case for all OpenGL implementations, correct? Is the issue handled by the other standards in some way?
 
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.
I don't think it'd be an essential issue. In theory uploading depth could be of benefit for impostors, but at the same time it be a very slow replacement for writing gl_FragDepth, therefore making this usecase unlikely with uploads. It would be conceivable that you have an offline/statically compiled depth in a preprendered static scene and you substitute parts of a  scene with depth-tested realtime 3D, however this technique too would require a per-frame upload since you can't clear the depth texture to previous values, and depth test without write is not generally useful to write out geometry.
 
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.
Sounds fine to me.
 
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.
I can't comment if another prefix would be required, I don't think I'd care either way. Although it would seem slightly more correct to use WEBGL_, since it does change a standard behavior, I'm not sure if the sake of correctness in this particular case is adding or subtracting usefulness.