Am Thursday 06 August 2009 14:08:20 schrieb Henri Verbeet:
2009/8/6 Stefan Dösinger stefan@codeweavers.com:
That's why I still think we should use behavior flags as a last resort, and use other problem specific ways where possible and reasonable. (an example for what's not reasonable: Clone the entire private data code in ddraw to avoid the AddRef - I clearly prefer a behavior flag for that)
Actually, if you wanted to avoid create flags, handling that AddRef in ddraw would be less ugly than what patch 4 does. (And no, you don't need to clone resource.c for that, just return the flags from resource_get_private_data() and its callers, and immediately call Release() in the appropriate case in ddraw.)
True, that sounds like an idea.
I still don't see the problem with the SetRenderState(or any other state set call) though. For the app CreateDevice and Reset are atomic calls. We have full control over the wined3d device. If wined3d's setRenderState suddenly gets any new side effects a SetRenderState in CreateDevice is a pretty small concern. WineD3D will not start recording a stateblock after creation(in which case SetRenderState DOES have side effects¹).
I don't see in which situation it would matter that the WineD3DDevice initial state is different from the state we return it to the app. All the app bothers about is the D3D8Device's initial state(or reset state), and for that the outcome is the same. Thus I am more worried about the number of create flags getting out of control than a SetRenderState doing something unintended.
¹: This is why I need a create flag for SetRenderTarget: If a stateblock is being recorded, I can neither update the viewport from d3d8/d3d9, nor attempt to restore the old viewport in ddraw - the change would go into the recorded stateblock, not the initial one.