http://bugs.winehq.org/show_bug.cgi?id=5955
------- Additional Comments From stefandoesinger@gmx.at 2007-21-03 17:04 ------- The winecfg this is easilly answered: There is no winecfg option and there will never be one. The DirectDraw renderer should be opengl by default, and autodetected to fall back to gdi if no opengl libs are available, or only uppon direct request.
The issue that DDraw fails to load completely without opengl is because the DDraw software renderer is built into wined3d.dll and wined3d.dll is dynamically linked(at load time) to libGL.so. Having the sw renderer in wined3d allows us to use it as a fallback if Direct3D blitting operations(StretchRect, CopyRects) are not supported by the opengl code.
What needs to be done to make DDraw work without gl is to replace the dynamic load-time linking with lazy linking. The last time this was discussed the idea was to link wined3d (dynamically) to out opengl32.dll(or native opengl32.dll on windows). OpenGL32.dll does the lazy linking against libGL.so. For initialization opengl calls our display driver, winex11.drv or winequartz.drv which does the platform dependent initialization. Platform independent calls go from opengl32.dll to libGL.so.
I dislike that idea because I do not think it is good to put abstraction layer above abstraction layer above abstraction layer in performance critical things like 3D graphics. In the worst case we have d3d9->wined3d->opengl32->winex11->libGL.so
Also, if I understand the linking concept correctly, dynamic load time linking results in faster calls than lazy linking. Thus if we take even the simplest approach and implement lazy linking in wined3d, this will result in decreased Direct3D performance. It would be a minor decrease, but still a decrease. Honestly I think that there are more Direct3D users than users who use DirectDraw on a non-opengl display. I think Gentoo is the only distro that offers a way to compile wine without opengl, except manual compiling with fidling with configure params. Keep in mind that you do not need a 3d accelerator. The Mesa3D software renderer is perfectly enough, and it maybe even gives faster performance than our software ddraw renderer.
If you want to implement lazy linking to libGL.so the first step would be a discussion of the approach on wine-devel. My personal preference would be not to implement lazy linking and close this bug as invalid, or wait for a general opengl loading cleanup which moves wined3d over to wgl(opengl32.dll), which we will need if we want to use our (future) Direct3D10 implementation on windows xp(and thus close the bug as later).