pbuffer in OpenGLES for off screen rendering

Question

jt2090 Author

Level 1

0 points

pbuffer in OpenGLES for off screen rendering

I'm trying to figure out the fastest way to blit an offscreen buffer on to the screen, preferably using opengles.

I'm now using an image which I init with glTexImage2D with a NULL and subsequently call glTexSubImage2D. So my paint loop looks like this:
-bindtexture
-glTexSubImage2D
-drawtexture
-swapbuffers

glTexSubImage2D is not fast as it is not designed to be called repeatedly
in the render loop.

The docs point to something called a pbuffer, but I'll be darned if I can get it to work. The docs dont appear to match the descriptions or apis of any other
available google info.

So my question is how to properly set up a pbuffer and does it work at all?

Primarily, do I have to create a seperate surface using CreatePBuffer surface,
as well as my screen surface? If so then how to fast copy between the pbuffer surface and the screen surface and does this extra copy negate the benefits of using the pbuffer?

I've seen lots of sample code about the setup and attaching a texture to the pbuffer surface, but nothing that shows how to update the screen with this non screen surface.

Thanks for any insight

Mac OS X (10.5.2)

Posted on Apr 26, 2008 7:08 PM

Reply

Answer 1

dsyu

Level 1

0 points

Apr 29, 2008 5:11 PM in response to jt2090

I haven't tried experimenting with PBuffers in OGLES yet, but based on reading the docs, they behave somewhat differently than regular OGL PBuffers (where you can basically copy back and forth via glRead/Copy/DrawPixels).

For OGLES on the iPhone, it sounds like PBuffers are really for "render to texture" use only? Notably, docs on eaglSwapBuffers note that if the current surface is a pbuffer, the call won't work, which suggests to me that pbuffers cannot be directly displayed. Likewise, GLES doesn't support glDrawPixels to the front buffer. The main functionality I could see for pbuffers was to either associate the buffer with a texture object, or just copy the pbuffer contents to a texture object's defined texture data using glReadPixels or glCopyTexImage2D or the like.

You could, I guess, draw to the pbuffer, and then when it came time to actually draw to screen/front, draw a textured quad with the pbuffer's contents as the texture, but I have to believe this isn't going to be either fast or really want you want in the end.

Apologies for the rambling.

Reply

Answer 2

Apr 29, 2008 6:03 PM in response to jt2090

Have you looked at the GLPaint example? That's using off-screen rendering and then maps the buffer onto a texture to render into the main view.

Reply

Answer 3

jt2090 Author

Level 1

0 points

Apr 29, 2008 11:04 PM in response to EagerEyes

I've looked at that example, and it does help with repect to how to setup the
the FBO and what to do in the Render loop.

What is the call to render a pixel or set of pixels then to the texture?
IOW what is the replacement for glTexImage2D that lets me supply a pointer to an array of colored pixels? I tried using

glVertexPointer(2, GL_SHORT, 0, pMyBackBuffer);
glDrawArrays(GL_POINTS, 0, (512*512)); //yes I'll pull out the multiply later

but that just crashes.

Reply

Answer 4

dsyu

Level 1

0 points

Apr 30, 2008 10:18 AM in response to jt2090

glReadPixels or glCopyTexImage2D will copy from the pbuffer to a memory buffer or the active texture respectively. There's also eaglTexImagePBuffer that I believe basically points the texture directly at the pbuffer so it's always "in sync" with the pbuffer.

Reply

Answer 5

jt2090 Author

Level 1

0 points

Apr 30, 2008 11:17 AM in response to dsyu

Thanks.

I don't want to copy from the texture to memory. (I'm not doing post processing of an already rendered scene, I'm blitting the scene myself).

I want to copy from memory to the texture. It looks like using a pbuffer requires context switching in the render loop which seemes to be very slow.
I guess I'm stuck with glTexSubImage2D...

Reply

Answer 6

Apr 30, 2008 11:42 AM in response to jt2090

I still haven't looked through the entire example, but initWithFrame in PaintingView.m in the GLPaint example has the setup for the off-screen framebuffer object and the binding to the texture. It's commented pretty well, so it shouldn't be too hard to follow. I don't entirely understand why they're not using CopyTexSubImage2D, but I guess it has to do with how OpenGL ES does things.

Reply

Answer 7

jt2090 Author

Level 1

0 points

Apr 30, 2008 11:57 AM in response to EagerEyes

I'm able to follow the setup and the render portions of the example, and thanks for pointing me to it BTW. I was able to duplicate the functionality of those two parts (the setup and the render). However, the renderLineFromPoint function is quite confusing to me. I have a simple buffer of 16bit color values. Shorts in a buffer. I want to plot those values as pixels. You are suggesting using CopyTexSubImage2D. How would CopyTexSubImage2D read from a short * ? The goal here being to avoid the glTexSubImage2D call.

thanks

Reply

Answer 8

jt2090 Author

Level 1

0 points

Apr 30, 2008 12:37 PM in response to jt2090

Here an example that uses a 'Renderbuffer' instead of a framebuffer.
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacPr ogGuide/opengloffscreen/chapter_5_section5.html

In reading along it looks like perhaps renderbuffer is what I want. However, I get to the part "Draw the 2D pixel image to the renderbuffer" and there is no code! ?

Reply

Answer 9

Apr 30, 2008 12:40 PM in response to jt2090

We're talking about different things then. I need to copy stuff from the framebuffer in my application, so copytexsubimage2D makes more sense. If you have the image in some kind of array, you'd have to look at DrawPixels or perhaps (if you don't need to redraw from that buffer a lot, or can copy into a texture) drawing the data as GL_POINTs.

Reply