RFC: d3d8 refcount implementation
Stefan Dösinger
stefandoesinger at gmx.at
Wed Nov 15 02:36:01 CST 2006
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
More information about the wine-devel
mailing list