It is pretty much already a requirement to call getSubImage / getViewSubImage every frame; if you don't then it means you haven't rendered anything and the previous frame might be reprojected. We just need to make it more clear in the spec, afaiu.

It seems strange that textures become valid again at the beginning of the frame before getSubImage / getViewSubImage is called to signal that a refresh of the layer is needed.
This also breaks the 'needsRefresh' attribute since now you will be able to use the texture without ever calling these methods.

It is pretty much already a requirement to call getSubImage / getViewSubImage every frame; if you don't then it means you haven't rendered anything and the previous frame might be reprojected. We just need to make it more clear in the spec, afaiu.

That is not correct. Only projection layers have a SHOULD that they should refresh each frame (by calling getSubImage / getViewSubImage). Other layer types can refresh at will since the compositor will keep the layer in the correct projection.

I think there is a confusion here. Who said the textures become valid BEFORE getSubImage / ViewSubImage is called? No, in my understanding the call to getSubImage returns you a valid texture to use; until then - you don't have a texture to render to. Even the fact that it returns the same JS object (WebGLTexture) doesn't change that: until you call getSubImage that texture is "invalid".

That is not correct. Only projection layers have a SHOULD that they should refresh each frame (by calling getSubImage / getViewSubImage). Other layer types can refresh at will since the compositor will keep the layer in the correct projection.

It is correct for ANY layer which you want to update. If you did not call getSubImage then it will be reprojected. It is just much less likely that projection layer got skipped the update, but otherwise the behavior is the same for all layers.

OK. I think we're actually in agreement:
In order to get a valid texture, you MUST call getSubImage / getViewSubImage.
The texture that is returned from these calls is only valid until the end of the frame and will become valid again after calling getSubImage / ViewSubImage with the same parameters (Layer, view, etc)

Yes! Sorry, my wording was confusing.

@Artyom17 Do we need to wait until the WebGL group defines this behavior or can we describe it in the layers spec?

Also, are there public notes from that meeting that we can refer to?

I am not sure if the notes are public, but I'll send you a link.
As to behavior - we prototype it first (I am working on it), prepare the change for the spec (at least a draft of some kind) and then re-verify with WebGL WG.

@artyom, it's probably better that we change this issue so it's clear that this is mostly about the texture lifetime and behavior. Should we rename it or open a new one?

@toji , can you help me with the spec text on the texture?

/agenda What should be the behavior of the color and depth textures?

I agree with @cabanier that either we should rename this issue or open a new one about how webxr texture state should change in rAFs.

I'm still waiting from @toji. I'm unsure how we should phrase the behavior of these textures.

Addressed with PR #201