Request: FBO can use "default" color, depth and stencil buffers

Minor request:
an FBO can use the color, depth and/or stencil buffer of the FBO 0, i.e. one can attach to an arbitrary FBO the system provided color buffer as a color buffer and along those lines the depth and stencil buffers. One use case is to simulate multiple depth and stencil buffers. I suspect that it might be that one will not be able to attach the depth buffer from the system but a stencil buffer from elsewhere to the same FBO, and visa-versa.

One can simulate this by making one’s own stencil, depth and color buffers and just carry on as if that is what to render and at the end of the frame to blit the color buffer to the window color buffer; but that seems silly and sounds like a hack to get around an API issue; Moreover, we will see OpenGL (not just OpenGL ES) on embedded systems where bandwidth is tight and the resolutions are insane, so I think this is worthwhile API to add.

One can simulate this by making one’s own stencil, depth and color buffers and just carry on as if that is what to render and at the end of the frame to blit the color buffer to the window color buffer; but that seems silly and sounds like a hack to get around an API issue

It’s funny; when I suggested this very idea (or something functionally indistinguishable from it), your reply was, “why not just ‘fake’ your own framebuffer via FBO’s and at the end of the frame blit your renderbuffer/texture to the framebuffer?”

So when did that become “silly”? :smiley:

an FBO can use the color, depth and/or stencil buffer of the FBO 0, i.e. one can attach to an arbitrary FBO the system provided color buffer as a color buffer and along those lines the depth and stencil buffers.

So, what happens when those images change size? Which they’re allowed to do, since they’re not owned by OpenGL. What happens to the pixel ownership test? And so forth.

There’s a reason why my version explicitly suggested a locking API. By locking the default framebuffer, it gives the user the ability to release and reacquire the framebuffer images on resizing. Or the user can prevent the size from changing via various window-specific mechanisms, and thus don’t have to deal with the issue at all.

I actually didn’t cover the pixel ownership test issue, which would probably be especially sticky.

One use case is to simulate multiple depth and stencil buffers.

What do you mean by that?

IIRC this is how framebuffer works in GLES on iOS (at least from my very brief experiences with it). You essentially attach ‘window’ surface to an RBO and then are on your own.

[QUOTE=Alfonse Reinheart;1254418]It’s funny; when I suggested this very idea (or something functionally indistinguishable from it), your reply was, “why not just ‘fake’ your own framebuffer via FBO’s and at the end of the frame blit your renderbuffer/texture to the framebuffer?”

So when did that become “silly”? :smiley:

So, what happens when those images change size? Which they’re allowed to do, since they’re not owned by OpenGL. What happens to the pixel ownership test? And so forth.

There’s a reason why my version explicitly suggested a locking API. By locking the default framebuffer, it gives the user the ability to release and reacquire the framebuffer images on resizing. Or the user can prevent the size from changing via various window-specific mechanisms, and thus don’t have to deal with the issue at all.

I actually didn’t cover the pixel ownership test issue, which would probably be especially sticky.

What do you mean by that?[/QUOTE]

You are right; epic brain fart on me for not considering what happens if the window changes size… hmmm… my only thought is the following:

it is a GL applications responsibility to handle what happens when the windowing system changes the buffer size, i.e. if the window system changes the window size then the application is expected to do whatever it is supposed to do to correctly use those buffers (I recall that an FBO can have attachments of different sizes with some rule specifying what happens when the sizes are different).

This has the advantage of being simple without adding anything. As for pixel ownership test, things can get ugly depending on the window system and how the window buffer was made. A simple ugly thing would be this: if an FBO has an attachment from the windowing system then the pixel owner ship test applies and those pixels for which the pixel ownership test fails, it is undefined if any value is written even to those buffers not coming from the window system.

As for iOS, _kyle; iOS makes on create an FBO and color render buffer at GLES1/2 application start mixed with iOS specific calls.

Yes. If i understand you correctly this is exactly what you want. To manage default framebuffer attachments as GL objects - of course its gonna need system specific calls now.

Probably image_external EGL api could be reused to have this ‘cross platform’ in GL (in ‘near future’). Actually it may be worth having a look there as it may even be possible to do right now (but i don’t follow all EGLImage specs/implementations to be sure).

Also, resizing the surface is probably not such a big deal. The frame during which resize happened is lost anyway and the application knows about the resize - i think the natural thing to do here on GL side would be to un-define rendering until next swap (this is under assumption that losing a frame is not a big deal in such conditions).

Rendering happens only in common rectangle.