[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



Hi,

I think the spec does mandate clearing/initializing all resources before usage. If that is not done, the implementation is not secure, even wrt. renderbuffers. With some clever drawing and then readPixels afterwards it would definitely be possible to read data that's in renderbuffers attached to the FBO in use, even though direct reading is not possible. I don't see why any extensions would be any different, specifying a default clear value for added things if necessary would be most consistent with the rest of the spec.

-Olli
________________________________________
From: owner-public_webgl@khronos.org [owner-public_webgl@khronos.org] On Behalf Of Benoit Jacob [bjacob@mozilla.com]
Sent: Thursday, September 26, 2013 10:05 PM
To: public webgl
Cc: Daniel Koch; Kenneth Russell
Subject: [Public WebGL] WEBGL_depth_texture unspecified case: sampling from an uninitialized depth texture

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
-----------------------------------------------------------