[Bug 5955] DirectDrawCreate crash on non-OpenGL desktop

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=5955





------- Additional Comments From stefandoesinger at 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).

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.