*** GMX Spamverdacht *** Re : [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.

[Stefan Dösinger]

Hi,
> Well I don't understand, what leaks ? Complex attached surfaces are still
> destroyed when we fire the root. The new patch takes Moto Racer 2 memleak
> issues in hand, and Nomad Soul leaks may not be related to this — not a
> regression because exiting led to crash before ( and remaining surfaces are
> simple surfaces ). In fact i was a bit unfresh when i posted the patch :P
> ..
My wait, I think I still do not really get what happens here...

Nomad Soul calls Release on the back buffer until it returns 0? Something like

while(Backbuffer->Release()); ?

Does it do that before releasing the front buffer, or after? I thought after 
releasing the front buffer, because that was some odd behavior reported with 
dune2000 which went away mysteriously...

Your patch, if I get it correctly, calls DeleteAttachedSurface only on the 
surface that is actually destroyed. If a surface is destroyed that is 
attached to a complex root then nothing else is done.

Just some questions to make sure I understand correctly:

* If the front buffer is destroyed and a z buffer attached to the back buffer, 
the z buffer will not get detached when back buffer is destroyed? So the 
reference to the z buffer will hang and the app crash will eventually when 
zbuffer->first_attached is accessed?

* If the back buffer is explicitly released so its refcount falls to 0 before 
the front buffer is destroyed, the z buffer is detached but nothing else 
happens. The back buffer will be destroyed when the front buffer is 
destroyed?

What does nomad soul do if you just return 0 when the ref of the back buffer 
falls to 0?

E.g

if(ref == 0)
{
    if(This->first_complex != this)
    {
        WARN("Attempt to destroy a surface that is attached to a complex 
root\n");
        return 0;
    }
}

And leave the rest as it is. That would be correct according to the msdn("A 
complex attached surface can only be destroyed by destroying the root"). I 
always thought this is enforced simply by the refcount, but well...

DDraw refcouting is horrible :-/ MS placed a lot of appcompat hacks into 
it(see the tests), and I already had loads of fun with it. I'm afraid that 
this will be fun for the future too...
-------------- 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/20060907/31af859a/attachment.pgp