d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
stefandoesinger at gmx.at
Wed Oct 18 04:23:38 CDT 2006
Am Mittwoch 18 Oktober 2006 10:18 schrieb Markus Amsler:
> I'm trying to solve bug 5872 http://bugs.winehq.org/show_bug.cgi?id=5872
> BF1942 calls GetDepthStencilSurface/IUnknown_Release and checks the
> refcount to be 0, but wine returns 1. (test hack attached)
> I have done some testing: The first call to GetDepthStencilSurface
> increases the refcount of the device, any subsequent call increases the
> refcount of the surface.
> On release calls the refcount of the surface gets decreased. If the
> refcount is 1 the release call decreases the surface refcount AND the
> device refcount.
> The exact same behaviour shows GetRenderTarget. d3d9 does also the same.
> Any ideas how we should implement this behaviour?
Doh - refcounting fun :-/
We know that surfaces, textures, ..., hold a reference to the device, which is
what you see with the increased device refcount. We have an
IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems
to have this AddRef call in IDirect3DResource_AddRef:
if(oldref == 0) IDirect3DDevice8_AddRef(This->myDevice);
I guess this is the first thing we have to change.
The next is that the auto depth stencil surface and the implicit render
targets seem to be created with a reference count of 0, that is why they have
a ref of 1 on the first GetRenderTarget, and why the AddRef from above
increases the device refcount. And the implicit surfaces aren't destroyed
until the device is destroyed. This will be fun to implement with our release
It could be that the implicit render target and auto depth stencil COM objects
are not COM objects in d3d's internal management and that they are
constructed in the first call to GetRenderTarget. But we won't be able to do
that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll.
But applications don't see what we are doing in wined3d anyway.
What you need for sure is a really good test case to convince AJ that all this
is correct ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20061018/668db04e/attachment.pgp
More information about the wine-devel