On Wednesday 22 August 2007 03:36, Chris Robinson wrote:
Over the past several days, I've been working with some people in #winehackers on a way to help solve the problems Wine faces with OpenGL.. namely the lack of useable onscreen pixel formats and broken child windown rendering. Here's a patch for your perusal in hopes to generate feedback.
What this does is, it renders GL to an offscreen buffer the size of the window it's rendering to, first trying a redirected window (if you have the Xcomposite extension), then falling back to GLXPixmaps (which may be slower, especially if you don't have AIGLX). The offscreen buffer is then copied to the window it should be displaying on using X, acting in a manner nearly identical to how Vista composites OpenGL (as described here: http://www.opengl.org/pipeline/article/vol003_7/ ).
I'll add some more info here as for sure people will ask about it. In short during the Winex11.drv window management rewrite Wine lost dedicated X11 windows for Direct3D/OpenGL (before everything had an X11 child window). This has broken windowed OpenGL for years.
Suggested solutions at the time were to use glxpixmap rendering. At the time that was only accelerated on Nvidia hardware. More about this below.
The other solution was the use of glScissor/glViewport to limit GL rendering to the place on the gui were GL was needed. This worked a bit on some drivers but there were SwapBuffers related issues, second it would also have clipping issues and the scissors/viewport override caused issues for pbuffers/fbos.
At the beginning of this year we looked at several methods of 'X11 child window injection' for GL. A few methods were tried. They had the same clipping issues as the scissors path but for the rest it worked. While it fixed most drawing issues, it got X event issues back. The win32 parent window would receive X expose events and in the end those would confuse programs.
The Xorg guys suggested that those events would get away when we would use automatic redirection using Composite. Even then the events are there though they are harmless but they still cause the same troubles.
The current solution takes advantage of (upcoming) changes in Xorg drivers. Thanks to Compiz and friends, developers are adding AIGLX, hw accelerated glxpixmap rendering and redirected gl rendering support to their display drivers. Right now all this stuff is still limited to Nvidia but other drivers are getting support. At least the intel driver and r300 will support it in Xorg 7.4 (you can get a preview of it in the TTM branches of both drivers, in case of Intel that's i915tex).
This solution is the best way to go. Luckily Microsoft made similar changes in Vista.
There is a speed hit, however. The DX9 swap chains demo, which gets about 280 FPS for me normally, gets about 80 to 90 FPS with the compositing method. It seems to be a ceiling though, as other more GPU intense apps have no extra noticeable slow down. Still, as an optimization, it can render directly to the window when it's being used on the whole window and the selected pixel format matches the current visual (this bit is disabled in the patch since it's for testing offscreen rendering, but it's simple to re-enable).
Demos like DX9 swap chains / 3DMark are heavily GPU limited e.g. they push the card to its limits. Normal programs are most of the time cpu limited. They are GPU limited ofcourse if you run the program on a system which the program considers lowend.
Regards Roderick Colenbrander