Refcounting fun

H. Verbeet hverbeet at
Sun Feb 12 17:55:09 CST 2006

On 12/02/06, Stefan Dösinger <stefandoesinger at> wrote:
> I meant IWineD3DSurface <=> IWineD3DTexture and Parent(IWineD3DSurface) <=>
> Parent(IWineD3DTexture). The first case has no consequences for ddraw, if the
> secound one is forced by WineD3D this would cause a connection between
> IDirect3DSurface9 <=> IDirect3DTexture9 and between {Direct Draw texture root
> surface} <=> {Other ddraw texture surfaces}
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.

> > For reference, the code for Release & CleanUp would look something
> > like this for the different objects:
> I could deal with such a Release / cleanup difference in ddraw, but I don't
> like the idea. I think it creates a too complex connection between WineD3D
> and the d3d libs.
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

> The important part is to set the surface's container when they are created,
> before the first AddRef() or Release() is called, and to set the container to
> NULL when the container is destroyed and before the surfaces are released.
> You can eighter track the containers in d3d9, or use wineD3D to get the
> container.
> Could this work?
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.
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

More information about the wine-devel mailing list