/agenda should we update the spec so texture are always cleared when calling getSubImage/getViewSubImage

So, the issue is that there is no obvious moment of time when the textures could be cleared or even invalidated. The current frame flow is as follows:

BEGINNING OF AF

<some code>
for each view:
   layerInfo = getViewSubImage
   gl.framebufferTexture2D(COLOR_ATTACHMENT, layerInfo.colorTexture)

   <some code>

   render
END OF FRAME

Note, the layer's color textures got detached from FBO after the frame is finished.

Thus, the question is: where exactly the clear should occur (if at all)? We can't clear it till the texture is attached to an FBO, but do we change the behavior of framebufferTexture2D?
Another option is to mark the texture as 'discarded' (but we can't discard it for real till the frame begins). In this case the clear should occur at the first attempt of rendering (at least in Chromium). But it is also kinda couter-intuitive since even the clear color could be unpredictable at that time (for example if the clearColor was changed somewhere between the framebufferTexture2D and "render"). Any thoughts?

@jdashg what do you think?

Spec that the textures returned by getViewSubImage are cleared/uninitialized (like other uninitialized webgl resources), which allows the implementations to do lazy clearing on draw, as we already do for all other webgl resources.

Don't worry about clearColor, as our implementations already handle this for textures, ensuring that textures are cleared to proper zero values regardless of the userland clearColor state.

@jdashg when EXACTLY do you clear / uninit the texture? At the first rendering attempt (i.e. the same as what happens when invalidateFramebuffer is called)?

Yes: It's an implementation detail, but generally just-in-time before the first draw to the resource. It's analogous architecturally to VK_ATTACHMENT_LOAD_OP_CLEAR.

got it

It seems we are all in agreement that textures should be cleared. I'll close this issue.