[D3D9] fix for SetFVF memleak [2nd try+patch]

[Ivan Gyurdiev]

Stefan Dösinger wrote:
> Am Samstag 14 Oktober 2006 20:53 schrieb Ivan Gyurdiev:
>   
>> H. Verbeet wrote:
>>     
>>> On 14/10/06, Ivan Gyurdiev <ivg231 at gmail.com> wrote:
>>>       
>>>> Exactly... so why is the refcount 1 *after* GetVertexDeclaration.
>>>>         
>>> Perhaps the declaration in only generated when calling
>>> GetVertexDeclaration(). If you call it twice, does it return the same
>>> pointer?
>>>       
>> No.. I tried that too.
>> The same pointer is returned.
>>     
> Perhaps windows has a static internal vertex declaration? Does the refcount 
> increase when you call GetVertexDeclaration more often?
>   
Yes, the refcount increases.

======================

Here's probably what it does:

-> SetFVF()... sets FVF
-> GetVertexDeclaration() ... vdecl is null, but there is an FVF, grab 
the FVF, and make a declaration out of it. Store the declaration, and 
return it to the caller with refcount 1.
-> GetVertexDeclaration() again - just grab the stored declaration and 
follow regular code path, increasing the refcount.

Now, if the caller does not release the ref, it will leak memory [ 
because d3d certainly doesn't free it - not on SetFVF, or on 
SetVertexDecl ]. On the other hand, if the caller does release it, will 
it cause damage (1) on subsequent get calls? (2) at draw time... and how 
can we test that.

This whole part of the API is very strange, and completely undocumented. 
Perhaps those conversions don't matter at all in real applications. The 
primary reason they fixed stuff, is probably that the FVF codepath 
wasn't working together with shaders, so switching to decl internally 
caused improvement.