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 ;-)