Re: Changes to GLContext Regarding Antialiasing

[Jeff Gilbert]

As an addendum, we are also proposing to establish a shortcut to binding the offscreen buffer by allowing for binding the framebuffer to 0 (zero), and having this intercepted and interpreted as attempting to draw 'to screen' (really to the offscreen buffer(s). This allows us to forgo updating a decent amount of Layers code to reflect the (possible) presence of a separate draw and read buffer. Code already in place which records the current framebuffer, rebinds it, does operations, and then rebinds back to the previous framebuffer will not need to be updated. This reinforces the external apparent simplicity of GLContext, whatever may be necessary internally.

The alternative would be to update effectively all code that does not respect multiple bound framebuffers while potentially interacting with GLContext.

-Jeff

----- Original Message -----
From: "Jeff Gilbert" <jgil...@mozilla.com>
To: "dev-platform" <dev-pl...@lists.mozilla.org>
Sent: Friday, October 14, 2011 11:06:05 AM
Subject: Changes to GLContext Regarding Antialiasing

As part of bug 615976 "Implement WebGL antialiasing" ( https://bugzilla.mozilla.org/show_bug.cgi?id=615976 ), a number of non-trivial changes to GLContext are being proposed. (Mostly in GLContext::ResizeOffscreenFBO, in patches 2 and 5) To enable antialiasing, we need to first draw to a multisampled (MS) framebuffer, instead of drawing directly to our offscreen buffer.

Because of certain restrictions on MS framebuffers, it is not possible to use them as a drop in solution. (That is, we can't just switch to using MS framebuffers instead of single-sampled ones) For example, you cannot use glReadPixels on an MS buffer. It must first be resolved to a single-sampled buffer by blitting. GPU-local blitting is still not cheap enough to use after every draw, or alternatively before every read. To retain both accuracy and efficiency, blitting should only happen when necessary. As such, changes include keeping track of if a draw call has 'dirtied' the MS draw framebuffer. Then, before read calls, we check if the draw buffer is dirty, and if so, blit the framebuffers to update the SS read buffer. (Relevant code in patch 2 from lines 650 to 800) With these precautions in place, users of GLContext can use the normal provided GL functions without any change, and without having to worry about the buffers; this change is effectively invisible in that regard
.

There is one important instance where this is not possible. In GLContext, we also back our offscreen buffer with a texture, which means we can use the texture directly for compositing, instead of requiring a quite-slow read-back through the CPU. Since there is no way to otherwise know when a texture is about to be used, it's necessary to create a function that will blit the buffers if needed, just as we do before all read calls. This is what will be used by the layers code to assure that the texture is updated.

Another field "int samples" will be added to ContextFormat, defaulting to 0. (Code located in Patch 3, though cf.samples is also forced to 0 for all platforms until support is added and confirmed in patches 5, 5.1, and 5.2) If a ContextFormat with "samples > 0" is used in the creation of a GLContext, the GLContext will make a best effort to setup a MS context with that many samples. (currently "samples = 1" still creates an MS context, but with no extra samples) If creating an MS context fails, a normal single-sampled context is used.


Though it would be nice if such changes could be kept in WebGL-specific code, the requirements of layers compositing prevents this. In short, there would be no nice or robust way to signal from Layers to the WebGLContext when we need the texture updated. Also, though the impetus for adding antialiasing support is WebGL, the actual implementation of the GLContext is really best suited to staying there, rather than having to leverage implementation-related functionality into WebGLContext, which is really more concerned with acting as a wrapper. The changes made are relatively succinct, and careful to preserve existing behavior in the case of non-multisampled contexts, and with only minimal changes as required when multisampling is requested.


In effect, it will be possible to request GLContexts as multisampled, but (with one very specific exception) they will not differ in apparent behavior. In the default non-multisampled situation, the mechanics of GLContext are unchanged: Everything regarding multisampling is dependent on the presence of the additional multisampled draw buffer, while remaining transparent to almost all implementation details.

Nevertheless, this is a large change to the inner-workings of an important class, so I want to give people a chance to have any questions regarding the proposed changes answered, and to voice any concerns they may have.


-Jeff

PS: Some small changes to the patches are still ongoing as part of the review process, but the overall approach is stable.
_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Benoit Jacob]

After spending some time reviewing Jeff's patches and discussing with
him, I agree that this is the best approach.

Of course the part that's a hard sell, is that GLContext calls no
longer map 1:1 to GL calls. However, GLContext is still in principle
OpenGL conformant, which means that we could at any time drop that
code if we're OK to drop the features depending on it (WebGL
antialiasing). It's not like we're tying ourselves to a new API here.
On the contrary, as Jeff explains, these changes are needed to avoid
having to adapt a lot of GL/Layers code.

Benoit

2011/10/14 Jeff Gilbert <jgil...@mozilla.com>:

[Benoit Jacob]

Landed on inbound (bug 615976).

Benoit

2011/10/17 Benoit Jacob <jacob.b...@gmail.com>: