Oh, and to be clear: I don't see this as a backwards compatibility-breaking change. If we decided that yes, everything should be cleared then the worst that we do in introduce some unnecessary overhead for early apps that assumed a clear was necessary, but no content will break.

Somewhat related, if the spec adds new optional features that supply color or depth buffers to the app, i.e. pose-aligned AR camera frames or occlusion data, would this potentially use prepopulated attachments to the webxr framebuffer? That's a separate decision, but I think that requiring UA-provided ready-to-use framebuffers and discouraging apps from calling glClear would help add flexibility for this in the future.

For background (no pun intended), the experimental legacy-inline-ar implementation in Chromium had been using a color buffer prefilled with camera data instead of being blank, so a glClear from the app would break AR mode by erasing the camera image. The current immersive-ar implementation no longer does this since it composites the app-drawn image as a separate step, and adding camera frame access may be more useful as a separate texture anyway, but a hypothetical prepopulated depth buffer might be most convenient if it's directly available without copying.

For the Servo implementation of WebXR, it doesn't make a huge amount of difference whether user code calls clear or the device driver does. I'm not sure which clear colour would be used if it's the device driver though, are we going to say that it's the clear colour of the WebGL context for the WebXR content?

I think we'd want to specify it as transparent or opaque black, depending on whether or not the framebuffer has an alpha channel.

That would certainly be the easiest to implement.

I am supportive of the proposal: XRWebGLLayers should clear/invalidate their framebuffers prior to each frame.

But let separate clear from invalidation. What I think we should do is to INVALIDATE both color and depth buffers at the end of the frame, and this must be mandatory. Clear is another story and it could be a waste of GPU if I still need to re-clear it to something different from (0,0,0,0).

As per my comments in the last call, I would suggest that if we do define the buffers being cleared, we should also define what happens with the depth and stencil buffers.

For the depth in particular, there is no single value that will be ideal for all rendering engines, but the value that it is cleared to can be expected to be the same for all frames.

Many render engines will prefer an inverted depth buffer in order to reduce depth sorting artifacts, by interpreting "1" as the near plane and "0" as the far plane. Simpler WebGL samples are likely to use "0" as the near plane and "1" as the far plane, as this is the traditional OpenGL format.

For background on this particular optimization:

https://developer.nvidia.com/content/depth-precision-visualized

IMHO, it would be okay to let the depth and stencil be cleared by the platform; however, the value that it is cleared to should be configurable (at least allow it to be set once at XRSession initialization).

Please note that clearing the depth buffer redundantly has implications other than consuming fill rate. On tile-based-deferred rendering GPU's (most modern mobile GPU's), this operation also resets acceleration structures used to perform early culling operations. If done incorrectly or at the incorrect time during a frame, early culling can be effectively disabled, resulting in greater fragment shading costs and increased fill in subsequent render passes.

I agree with @Artyom17 that the browser should avoid needless clears by only clearing buffers when the developer chooses not to clear it themselves.

The only buffers the WebXR API should lazy clear are ones it specifically hands out to web developers. In the future, the plan is to have XR WebGL layers supply just a texture array to the web developer that they can use in any framebuffer of their choosing. So unless the depth buffer is supplied by the XR API for enhanced LSR purposes, I do not think we should get in the business of lazy clearing random buffers behind the developer's back.

We should use the clear values WebGL already defines as initial values. For depth, the lazy clear value is 1.0.

The only buffers the WebXR API should lazy clear are ones it specifically hands out to web developers. In the future, the plan is to have XR WebGL layers supply just a texture array to the web developer that they can use in any framebuffer of their choosing.

I have not heard about such a proposal. Is this for a new WebXR spec?

@cabanier , the issue I was referring to was the Use Texture Arrays with WebGL 2 one. It will be part of the layers module.

I'm going to back away from what I said earlier about it not making a difference for Servo... We're thinking of moving from an implementation that uses one texture which is locked during compositing, to an implementation that uses double-buffering (or triple-buffering, details still under construction). This is fine if the layer is cleared on each rAF loop, not so fine if it's required to keep state.

Put up a pull request to fix this at #866. Don't think it'll be controversial, but please take a look!