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

[Elie Morisse]

Le 28.08.2006 18:10:37, Stefan Dösinger a écrit :
> Do you mean the game releases the texture manually until it is destroyed??? 
> Urgh. Can you verify that this doesn't come from DllMain() in 
> dlls/ddraw/main.c?
> Nop I checked, and anyway can't be because this occurs also when switching resolutions.
> The msdn suggests that destroying the root destroys all sublevels, and it 
> would be sane, because you create all surfaces with one call, so you should 
> destroy them with one call.
>
> If you are right, then every single ddraw application that works on wine now 
> would leak memory on windows.
> 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 ..
> I suspect that something else, like a bad 
> capatiblity flag, causes weird behavior by the app, so it behaves differently 
> in wine then on windows, or that the real refcouning issue is that the front 
> buffer shouldn't be destroyed when the app messes with the back buffer. The 
> other thing could be that this application has an registry hack on windows: 
> Windows XP has ddraw compatiblity regitry entries in 
> HKEY_LOCAL_MACHINE\Software\Microsoft\DirectDraw\Compatiblitity. Can you 
> check if you find Nomad Soul there? I have no idea what these entries mean, 
> can you try to remove the whole compatiblity key and try nomad soul again? 
> (well, backup first :-) )
> Hmm I'll try as soon as I procure it.
> But first tell me if i misunderstood something ;-)
> It is hard to prove that a surface is really destroyed or not, but you can 
> write a regression test which accesses a back buffer which belongs to a 
> complex back buffer / front buffer compound after the front buffer has been 
> destroyed?

*** 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...