d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue

[Stefan Dösinger]

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 
code :-/

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20061018/668db04e/attachment.pgp