Copy on present in OpenGL backend

[kvark]

Currently, the GL backend is built in such a way that we copy the full frame on present(). This is a waste of fill-rate and performance that we've been trying to eliminate. The plan was to modify surfman in a mystical way that would let us do this - servo/surfman#202. However, digging into EGL as well as asking around on Khronos slack proved this to be impossible. The best we can do is - avoid context sharing in GL. So the problem of copy on present remains unsolved.

I've been thinking that perhaps in most cases where the swapchain is used, there should be no need for a copy at all. Most applications would render to the swapchain image in a single pass, and the depth is discarded after it. So what if we create the EGL surface with all of color, depth, stencil, just in case, and try to use it aggressively? Given the render pass boundaries in this API, it seems like it could cover most cases:

Cases

Case A: rendering to color only.
GL backend sees that an application only renders to the color, it binds the main framebuffer, and the copy is avoided.

Case B: rendering to color and depth, the depth is cleared and discarded at the end.
We see the clear+discard on the depth, and we figure out that we don't actually need to consider the user-provided depth image. So we just use the default framebuffer again, and the copy is avoided.

Case C: rendering to color and depth, depth is test-only, loaded from a depth pre-pass.
We see that the depth is discarded, so we can use the default framebuffer. However, we also see that the depth is loaded, so we issue a copy from the user-provided depth into the main FBO depth, first, before starting a pass.

Case D: rendering to color and depth, and depth is stored (not discarded).
We proceed with the logic of B/C, but after the pass we issue a copy from the framebuffer depth to the user-provided depth.

Case X: rendering with other colors alongside the swapchain. I don't see how we can reasonably support that in GL backend. We'll have to document and assert on that.

Case Y: user-provided depth is not a 24-bit depth. I don't think we can deal with that, unfortunately.

Analysis

This requires some logic to be implemented, for tight integration between EGL and rendering. The benefit is avoiding the copy of color in all cases. However, another cost is that some cases would involve a copy of the depth, which roughly have the same size...