PBuffer without a regular context?

I dont have an answer, but I'd like to recommend that you look into using Frame Buffer Objects instead of PBuffers.

Quote:

Original post by Andrew Kabakwu I dont have an answer, but I'd like to recommend that you look into using Frame Buffer Objects instead of PBuffers.

Thanks for your reply. However, it's quite unhelpful (as you already mentioned):

1. __WHY__ do you suggest I look into FBOs? FBOs are a good replacement for PBuffers if you are doing render-to-texture (which I'm not).

2. I'm aware of FBOs and as far as I see they won't do anything for me. They don't help me with the non-visible context as you still need context for them (either a normal window or a PBuffer). Which brings me back to my question, what are the benefits of a PBuffer over a regular non-visible window.?

1. FBO can be used not only for rendering to texture. Use renderbuffers instead of textures as color/depth/stencil attachments.

2. I think FBO's will have better performance if you will need serveral FBO/PBuffers. Switching FBO is cheaper than switching to different PBuffer.

Regarding your context issue - I do not think you can create nor FBO, nor PBuffer without proper context (at least on Windows). Just create invisible window and use it to create PBuffer, or create normal OpenGL context and use FBO's.

I've tried that on Linux, using Qt's QGLContext, without a Window, and it worked, but no idea if it would work on Windows. But i still used a context, you can't use OpenGL without a Context.

A pbuffer is OpenGL functionality and all OpenGL functionally needs a context under the hood to connect to the correct driver to run the functionality on.

The difference between a pbuffer and a non-visable window is that of 'pixel ownership'. With a regular window when you perform rendering the final output is subject to an ownship test. With a regular window what this means is if you OpenGL context is partly coverted by another window, or indeed off screen, the ownership test will fail and the output results are undefined (so reading back could give you what you expect or it could be garbage). Although this might only be a problem with reading from GL_FRONT of a double buffered context.

pbuffers on the other hand are off screen buffers and as such are not subject to the ownership test. They are also useful for maintaining state seperate from your main context.

FBOs might be a better fit, depending on what you are doing, as they are 'lighter' than pbuffers and, if you need to access to the pixel data again for a shader via a texture, don't involve bizzare proxy texture binding, nor do you have an issue of resource ownership as an FBO exists in the same 'namespace' as the context it was created on; pbuffers on the other hand are their own context thus don't share any resources with the main context until you call wglShareLists() to ensure things are correctly shared.

---

As a side note, I've noticed an almost kneejerk reaction for people to recommend FBOs without really thinking beyond the shiney factor. Hell, in a recent thread on font rendering they were recommended when they weren't remotely the best solution. As an ex-opengl user and writer of two articles on FBOs I find this trend both amusing and sad at the same time as people still clearly don't understand what it is they are for and are simply not thinking before answering.

Quote:

Original post by phantom Although this might only be a problem with reading from GL_FRONT of a double buffered context.

Pixel ownership test applies to both front and back buffers. Reading back from a hidden or covered part of the backbuffer will also return undefined results.

Thank you both Rob and Yann. That seems clear-cut then. I'll definately need a PBuffer instead of a non-visible window.

I'm looking into creating some unit-tests for my renderers to make sure they keep working correctly as I refactor them. For this I'd rather not have a window visible as the test harnass is basically commandline. I'm planning to create images of what I expect as output, and then rendering and grabbing the backbuffer to compare with the expected output. Hence I'm not particularly fussed about using FBOs as I simply need to read back the results to the CPU.