Hi,
AFAIK, there are four targets OpenGL can draw to on X: X windows, Pbuffers, FBOs or GLX pixmaps. EXT_framebuffer_object should be the most interesting approach, as it's supposed to somewhat similar to Pbuffer rendering, but supposed to be more portable and faster: "This extension defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window-system." But I guess a FBO or a GLX pixmap would still introduce a similar performance hit compared to Pbuffer rendering?
FBOs are very interesting for this, but the mail performance issue is to read back from the video card. Video cards are mainly output devices, reading from them is slow. AFAIK the driver even has to use PCI transfers for that, because AGP isn't designed for reading back data. I could be wrong with this, and I don't know how PCIe affects this.
Forest Hale (and Lionel Ulmer) suggested a different, but probably more hacky and difficult approach (from http://wiki.winehq.org/OpenGL): "I would recommend overriding the glViewPort and glScissor calls, as well as gl[En/Dis]able GL_SCISSOR_TEST, and arrange the glViewPort for the proper projection for rendering, but use glScissor to set the region that can be rendered in the current DC, also there should be no slowdown from having scissor test permanently on."
That is the plan for Direct3D, where I consider that easier because WineD3D can control GL, without the chance that the app does opengl calls which interfere.
Sorry, I don't get this. Windowed applications should not be affected? There is no problem with windowed OpenGL applications, they are not affected by bug 2398 anyway. Only applications with embedded OpenGL viewports are affected, so a workaround would only need to target embedded viewports...?
This comes from the way DirectDraw apps handle windowed Direct3D. See my description for the IWineD3DDevice::SetFrontBackBuffers call: http://article.gmane.org/gmane.comp.emulators.wine.patches/23491
Stefan