Refcounting fun

[Stefan Dösinger]

Hi,
> Well, I agree it's not a great construction. I'm just not sure if
> using the container in that way makes things much better. It would
> mean having to retrieve the surface container in each call to
> IDirect3D9Surface_Release.
Do you think it might be a performance problem?

> You can't easily store it in d3d9 since  
> when the wined3d surface's container changes the d3d9 container would
> have to change as well, but you can't call much of anything in d3d9
> without adding another callback. 
Can containers change? I thought that the container is set at creation time 
and can't change?

> Also, you're now duplicating the 
> relation between a surface and it's container in d3d9, while I don't
> think d3d9 should know that much about the specific implementation in
> wined3d. That doesn't mean I couldn't live with going with that
> solution, just that I'm not sure what the advantage would be.
I think that we can't avoid keeping certain management things in d3d7/8/9 
because of the differences between the versions.

I've had a look at your proposal again, and I could handle it in ddraw. The 
only problem is that I have to be able to release(and destroy) the 
wined3dSurface without having the ddraw surface destroyed. This happens when 
I switch the surface implementation, or when I lose the primary surface due 
to a screen resolution change(Restoring the surface re-creates the 
WineD3DSurface in this case). The best solution for this would be to allow 
the cleanup CB to be NULL.

My opinion is to use the container in the d3d9 addref and release function, as 
it uses only methods that COM and WineD3D already have, and both d3d9 
surfaces and wined3d surfaces are valid COM objects(they have their own 
refcount) and we avoid callbacks. Furthermore the d3d9 and wined3d objects 
are clearly seperated.

What's the opinion of the other directx people? Lionel? Oliver?
-------------- 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/20060213/c63a5565/attachment-0001.pgp