Refcounting fun

[Stefan Dösinger]

> Connecting the parents' refcounts wasn't really the idea, at least not
> directly. I think it's probably a good idea to have as little logic in
> the wrappers as possible. However, they are of course indirectly
> connected through wined3d; The connection between IDirect3DSurface9
> and IDirect3DTexture9 is the reason for doing it in the first place.
Right, I can't imagine how a IWineD3DTexture <=> IWineD3DSurface connection 
can help you, except if you use that connection to build the Direct3D9Texture 
<=> Direct3D9Surface connection.

> I'm not sure that connection is much more complex than the way it
> currently is. Right now the d3d7/8/9 wrapper objects are responsible
> for cleaning up their wined3d object, while with that change the
> wined3d object would become responsible for deleting the d3d7/8/9
> objects.
Err, the WineD3D objects clean themselves, it's the duty of the d3d7/8/9 
objects the release them if they are not needed any more. If the WineD3D 
refcount falls to 0 then(the general case), the WineD3D object will clean 
itself. If the object is in use somewhere internally in WineD3D, it's 
destroyed as soon WineD3D releases that refcount.

The "exception" is when WineD3D asked d3d7/8/9 to create objects via 
callbacks(e.g. the callback during texture creation), then wineD3D releases 
the parents of the objects it created. The parents take care for cleaning up, 
and they release their WineD3D child.



> It probably would. However, it's not all that different from the other
> option. The main difference seems to be that you don't separate the
> CleanUp and Release code, but use the parent in combination with a
> reference count that's guaranteed to be one as some sort of flag to
> decide whether to do the entire release code or just the cleanup part.
I personally think that we should stay withhin the possibilities that COM 
gives us, instead of adding cross-library destroy callbacks. Why? Read the 
current ddraw surface creation code and the surface release code, and follow 
the callbacks between the different ddraw / surface types.

> That, and in order the use the container in that way you either have
> to store it somewhere in d3d7/8/9 or retrieve it on every call to
> Release. I'm not sure if that reduces the complexity all that much.
> Regardless of whether separating the Release and CleanUp code would
> make things a lot more complex, I do think it's somewhat cleaner.
> Also, note that most (all?) wined3d objects already have a CleanUp
> function.
Well, at last it's up to Alexandre to decide which way to take.

I also think that seperated release / cleanup code makes it easy to do sloopy 
and incorrect refcounting. The ddraw code is full of bad surface reference 
counting, which is cascaded by a bad reference counting in ddraw, which works 
for most games, but breaks e.g. Empire Earth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060213/ee052ff0/attachment.pgp