D3D7 -> WineD3D, 2nd attempt

Stefan Dösinger stefandoesinger at gmx.at
Wed Oct 12 11:15:12 CDT 2005


Hello,
> This should be managed by reference counting wherever possible, if ddraw
> holds a reference to the surface then it won't be released when the device
> is released.
I tried to do this, but I ran into problems:
I have a DirectDrawSurface, a Direct3D7Device, WineD3DDevice and a 
WineD3DSurface. The DirectDrawSurface is the Parent of the WineD3DSurface, 
and the WineD3DSurface is used as the Front Buffer for the WineD3DDevice. The 
Direct3D7Device is the parent of the WineD3DDevice.

Now I want to Destroy the Direct3D7Device because the application tols me to 
do so. While doing so I have to Destroy the WineD3DDevice for cleanup. The 
WineD3DSurface has to be destroyed too, otherwise it would be without it's 
WineD3DDevice. But I must keep the DirectDrawSurface.

Making the DirectDrawSurface survive the WineD3DDevice->Release() is easy - A 
AddRef does this job. But in this case the WineD3DSurface isn't destroyed. So 
my options are

*Destroy the WineD3DSurface manually before the WineD3DDevice->Release call. 
Problems: The WineD3DSurface is needed in WineD3DDevice->Release. Doing so 
causes a crash

*Do some RefCount magic and destroy the WineD3DSurface when the 
DirectDrawSurface's refcount reaches 1. Ugly in my opinion.

*Release only the WineD3DSurface in WineD3DDevice->Release, and not it's 
parent. This was the simplest approach, it was a modification of a few lines 
for the case dxVersion == 7.

*Any other possibilities that I didn't think of?

> It doesn't look like it, the only CreateWindow in ddraw is in
> surface_user.c when OWN_WINDOW is set, the comments note that OWN_WINDOW no
> longer works because of threading issues.
I decided to create my own window when constructing the Direct3DDevice if 
necessary. Using the X11 root window caused a crash due to an invalid X11 
call.



More information about the wine-devel mailing list