Sometimes it is better to double check your results.

It’s still true that a view object does not change the reference count that you can influence with AddRef and Release. But there is another internal mechanism that protects the resource from being deleted as long as there is a view object alive. This makes it not necessary to keep a reference to the resource after you have created a view. Additional the presented code to free a view that was created with a D3DX10CreateShaderResourceViewFrom is totally wrong. It causes a memory and resource leak. My only excuse for this mistake is that the samples in the SDK do it wrong too. Instead of executing this complex code it would be enough to simply release the view.

This all change the answer to the question form “You, only you.” to “You and other Direct3D 10 object you own”. This could although include effect parameters. Therefore you have to release the effect or set the parameter to NULL to free a resource for sure.

Update: I was wrong.

You, only you.

This answer sounds strange as in the world of COM reference counting there can be more than one single owner. With Direct3D 9 the device becomes a second owner of your texture as soon as you call SetTexture. You may already read that this is not longer true for Direct3D 10. For nearly every application this change would make no difference as they hold a reference to the resources anyway.

But with Direct3D 10 most times you assign a view instead of a resource to the pipeline. This could lead to the idea to keep only a pointer to the view and not to the resource itself. Especial in the case when the resource is immutable.

You may use code like this one:

Device->CreateTexture2D (… , &pTex);
Device->CreateShaderResourceView (pTex, NULL, &m_pView);
pTex->Release ();

It locks right but as soon as you assign this view to the device strange things would start to happen. The reason for this is that the Release call destroy your texture as the view doesn’t add a reference during creation. But the view will still point to the now invalid texture resource. Maybe the pointer becomes valid again after you create another texture. But even if this happen the result on the screen will not be the expected. To avoid this you should never ever release a resource as long as there is a view attached to it.

But this behavior of the view objects could hit you on another place, too. There are three D3DX10CreateShaderResourceViewFrom methods that give you a newly created shader resource view. As this view haven’t call AddRef for the resource it contains it will not call Release for it during its own destruction. Therefore you would have leaked a resource when you only release the view. Instead you have to do the following.

ID3D10Resource* pRes;
pView->GetResource (&pRes);
pRes->Release(); // GetResource have called AddRef.
pView->Release ();
pRes->Release();

You can use the same code if you want to store only the view of your own created resources. But it could be tricky to remember which view can be released direct and which one need this special handling.

But even if I got some Direct3D 10 applications working it would, as any other wrapper project, never a 100% replacement for the original Direct3D 10 on Vista. With every new D3D10 game it could fail again. The original version would never have such problems as this games we developed used it. Another problem would be the mapping of functions that have no OpenGL counterpart. And finally as any other emulation layer it would need some CPU time. Therefore a CPU limited application would possibly run faster with the original.