RFC: d3d8 refcount implementation

[Stefan Dösinger]

Hi,
Maybe its the best way not to construct the implicit surfaces in d3d8 at 
device creation time, only its wined3d counterpart(with parent = NULL). When 
GetBackBuffer or whatever is called, the wined3d backbuffer is returned, and 
a d3d8 surface created for it. The wined3d surface gets the d3d8/9 surface 
assigned to it, so future GetBackBuffers find it.

When the implicit surface is destroyed(aka refcount falls to 0) destroy 
it(without destroying the wined3d surface) and set the wined3d surface's 
parent to NULL.

When the device is destroyed wined3d destroys the implicit surface's parent ( 
while(IUnknonw_Release(parent)); ), and then the wined3d surface(which has 
parent == NULL then). This should never happen I think because when the 
implicit surface is created the device is addrefed. So in Uninit3D we can 
assume that the implicit d3d8 surface has been destroyed already.

Alternatively we can keep things as they are, and add some 
resource::isImplicit field to d3d8 / 9. Set this when the implicit things are 
created, and init their refcount to 0. In release, do not destroy resources 
with the isImplicit bit set. When the device is destroyed set isImplicit to 0 
and force the refcount to 1, then release as usual.

It should be possible to test which approach windows uses: Write a test case 
which calls GetBackBuffer, store the address, release the object. After 
allocating quite a bit of memory call GetBackBuffer again and see if the 
returned pointer is the same.

We need a proper test case for such refcounting hacks, but then it shouldn't 
be a problem to get a clone of Microsofts refcounting hacks into wine :-) (I 
cloned some ddraw refcounting hacks)

And once the wined3d refcount scheme is updated, I have to update ddraw.
-------------- 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/20061115/35c0cb13/attachment.pgp