On 1 September 2011 09:27, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am 31.08.2011 um 12:29 schrieb Henri Verbeet:
Well, DirectDraw 2D-only applications, but yes. All three people in that situation should either install a software GL renderer or explicitly set the "DirectDrawRenderer" registry key to "gdi".
My mail is a bit late, but the programs I'm mainly concerned about are Internet Explorer and Windows Media Player. If someone wants to play a game in a VNC X server that's a crazy enough setup that setting an extra registry key doesn't matter, but running IE in VNC isn't that unusual.
So you install a software GL renderer, use something that actually works with indirect GL, or set "DirectDrawRenderer" to "gdi". Plenty of reasonable options to make it work I'd say. If you really want to go out of your way to make this work you can even make the fallback to gdi automatic, but it would have to be before any surfaces or swapchains are created, I'm not putting the surface type switching code back in. Preferably this would work by making the surface type just go away on the wined3d side, and just not exposing any GL based blitters or 3D rendering.
It will make it impossible to run some apps out of the box(e.g. the ones currently affected by bug 2082, and old QuickTime versions). That's fine with
I'm not sure how this will make it more impossible to fix that bug.
Well, without opengl we can still render to the NULL hwnd, even if it has issues like not working with a compositing Window manager(Windows disables aero when a ddraw app doesn't specify a clipping window). OpenGL refuses to do that.
So you don't use GL to render to that. For simple blits, it should be fairly trivial to only use CPU blits when blitting to the root window. For actual 3D rendering you'd have to create an intermediate offscreen target to render to, which is probably somewhat harder. But then, with the GDI renderer this doesn't work at all.