Hi,
we’re using a Pbuffer to do some offscreen rendering, and then we’d like to take some of the resulting image and place it in a DC. The destination DC has no OpenGL context and is handed to us from an outside interface, so we have no control over it.
We’d like to avoid copying the data from the graphics card to the CPU and back to the graphics card as glReadPixels would do.
The problem is that copying from our Pbuffer DC with BltBit doesn’t seem to do work. Is there any other way to get data to our destination aside from using glReadPixels?
Use a DIBSection instead of a PBuffer. Windows supports offscreen rendering to a DIBSection, and the results can then be blt’ed to another GDI device context.
But you cannot render hardware accelerated with OpenGL to a device independent bitmap.
Means PFD_DRAW_TO_BITMAP formats use the Microsoft GDI generic OpenGL pixelformats.
GDI knows nothing about hardware accelerated OpenGL offscreen buffers of any kind!
glReadPixels is your only choice to read OpenGL rendered data from offscreen surfaces.
But you cannot render hardware accelerated with OpenGL to a device independent bitmap.
True. The OP did not state any requirement that this involved real-time rendering. If hardware-accelerated rendering is not a requirement, a DIBSection is a viable alternative.
Alternatively, it should be possible to create a DIBSection using the existing image in PBuffer memory. I haven’t tried this, but the GDI call CreateDIBSection takes a pointer to the memory block as a parameter. (It is up to the user to allocate the correct amount of memory). A pointer to the PBuffer should work fine (shouldn’t it?). There is obviously going to be a performance issue involved in creating a memory DC, creating the DIBSection, selecting the dibsection into the dc, etc. Again, whether or not this is a viable approach will depend on the performance requirements of the application, but in theory I think it would work.
We do want a hardware-accelerated approach, so we ended up implementing the glReadPixels approach. Though we would have preferred to avoid the extra pixel copy, the performance is acceptable for our needs.