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

Re: [Public WebGL] WEBGL_depth_texture unspecified case: sampling from an uninitialized depth texture



On 13-09-26 03:26 PM, Daniel Koch wrote:
> I think Chrome either initializes or clears all textures before use.
> While you can't provide initial data for an ANGLE_depth_texture texture
> you still should be able to attach it to an FBO and clear it.

Yes, but the novelty here, compared to the case of renderbuffers, is
that we would have to construct a whole new framebuffer (maybe with a
color attachment created just for that) and check its completeness. This
is different from the renderbuffer situation because with renderbuffers,
as they can only be readPixels() from and not sampled from, the only
framebuffer that we had to check for completeness was the one we were
_actually_ going to render to, so that 1) we didn't need to create a
dummy color buffer and 2) no matter how unpredictable framebuffer
completeness is (on actual drivers), we had a guarantee that we'd have
initialized renderbuffers before we'd allow reading pixels.

So here, rather than talking the slow and fragile route of creating a
dummy framebuffer just to clear the depth texture, I would rather treat
that case as an incomplete texture so that we would take the existing
code path that samples from a dummy 1x1 rgba(0,0,0,0) texture.

In fact, spec-wise, that doesn't make any difference --- but I think
that given that the case of incomplete textures is already specified,
the simplest way to handle the present case is to clarify that it is an
incomplete texture.

Benoit



>
> (Ken: feel free to correct me based on actual implementation details. I'm
> basing this from memory of some discussions I had with Greg.)
>
> -Daniel
>
>
>
> On 2013-09-26 3:05 PM, "Benoit Jacob" <bjacob@mozilla.com> wrote:
>
>> Hi,
>>
>> WEBGL_depth_texture introduces a basic possibility that does not exist
>> in the core WebGL spec: the possibility of an uninitialized texture.
>>
>> While uninitialized renderbuffers are only an implementation detail that
>> doesn't have any existence at the level of the WebGL spec, uninitialized
>> textures are different because they can be sampled from.
>>
>> The question is what should the spec mandate implementations to do when
>> executing code like this:
>>
>>   CreateAndTexImage2DSomeUninitializedDepthTexture();
>>   SetUpRenderingStateSamplingFromThatTexture();
>>   Draw();
>>
>>
>> It's not technically an INVALID_FRAMEBUFFER_OPERATION since the
>> uninitialized texture here is one we are sampling from, not one we are
>> rendering to. So should that be an INVALID_OPERATION?
>>
>> Note: I'm running into this while implementing support for
>> WEBGL_depth_texture on clients supporting only ANGLE_depth_texture. I
>> understand that Chrome already supports that. I would like to know what
>> is Chrome's current behavior there.
>>
>> Thanks,
>> Benoit
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------