WGL_ARB_pbuffer - is rendering accelerated?

[Jeff McWilliams]

After getting burned by the behavior described in item 14.070 of the OpenGL FAQ, I'm using WGL_ARB_pbuffer to render to an offscreen buffer.

I'm concerned about this comment in the faq:


An approach that might work for some applications is to render into a nonvisible window, such as a Pixmap under X Windows. This type of drawing surface can't be obscured by the user, and its contents should always pass the pixel ownership test. Reading from such a drawing surface should always yield valid pixel data. Unfortunately, rendering to such drawing surfaces is often not accelerated by graphics hardware. Does this apply to rendering to a pbuffer? If I render to it, is the rendering not accelerated by the graphics hardware?

Thanks,

Jeff

[marco_dup1]

Originally posted by Jeff McWilliams:
After getting burned by the behavior described in item 14.070 of the OpenGL FAQ, I'm using WGL_ARB_pbuffer to render to an offscreen buffer.

I'm concerned about this comment in the faq:


An approach that might work for some applications is to render into a nonvisible window, such as a Pixmap under X Windows. This type of drawing surface can't be obscured by the user, and its contents should always pass the pixel ownership test. Reading from such a drawing surface should always yield valid pixel data. Unfortunately, rendering to such drawing surfaces is often not accelerated by graphics hardware. Does this apply to rendering to a pbuffer? If I render to it, is the rendering not accelerated by the graphics hardware?

Thanks,

JeffThis is X11 and not windows. Its described GLXPixmap and not GLX(WGL)pbuffer. GLXPixmap has a X11 Pixmap associated with the offsceen buffer.

Have you looked at Frame Buffer Objects. This a new concept to do what pbuffer do.

regards

marco

[Jeff McWilliams]

Thanks, Marco.

Yes, I've looked at FBO. We have to support a lot of "older" cards (Quadro, FireGL, etc) so using something new like FBO isn't an option.