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?