[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 2:10 PM, Florian Bösch <firstname.lastname@example.org> wrote:
> On Thu, May 17, 2012 at 10:50 PM, Kenneth Russell <email@example.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?
Actually, the GLES conformance suite requires that OpenGL ES
implementations exposing OES_depth_texture must support uploading of
packed depth and stencil values. Unfortunately, it looks like
uploading stencil data is not supported by the D3D mechanisms that
ANGLE would use. (I don't know whether this would be supported
portably on D3D versions later than 9.)
>> 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.
I agree that it would be more correct to prefix the extension with
WEBGL_. However, if it turns out that we can remove the restriction in
the future, it would make more sense to leave it as OES_depth_texture.
This is the direction I'm leaning.
Thanks for the feedback.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: