Refcounting fun

[H. Verbeet]

> > 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.
I should have said "releasing", of course :)

> > 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.
Well, I agree it's not a great construction. I'm just not sure if
using the container in that way makes things much better. It would
mean having to retrieve the surface container in each call to
IDirect3D9Surface_Release. You can't easily store it in d3d9 since
when the wined3d surface's container changes the d3d9 container would
have to change as well, but you can't call much of anything in d3d9
without adding another callback. Also, you're now duplicating the
relation between a surface and it's container in d3d9, while I don't
think d3d9 should know that much about the specific implementation in
wined3d. That doesn't mean I couldn't live with going with that
solution, just that I'm not sure what the advantage would be.