On 26 January 2010 13:42, Stefan Dösinger stefandoesinger@gmx.at wrote:
If I let the buffer code create a wined3d_event_query then I'll have to create internal functions like this for _Issue and _GetData as well, and the real IWineD3DEventQueryImpl_Issue and IWineD3DEventQueryImpl_GetData would just be simple wrappers. I think that doesn't make sense since IWineD3DEventQuery is a wine(not wined3d) internal API as well. The event query implementation would offer two interfaces that provide the same functionality.
If you're only concerned about checking for faked event queries we could move the event and occlusion query faking into d3d9 and let WineD3D just fail normal query creation if there is no GL support. D3d9 is the only client library that needs faked event and occlusion query support. D3d9 has enough information to return dummy data on its own if wined3d doesn't provide the real queries.
Do you have other concerns that would require a wined3d internal and wined3d external event query interface?
Not for this patch. In the long term I'm not sure if we want to stick with the current COM-style public wined3d interface, but that's mostly a separate consideration.
As for this actual patch / series, I'm sure there are plenty of different ways you could implement this, but it seems to me that using IWineD3DQuery is one of the impractical ones. Using wined3d_event_query is just a suggestion, if you can make things work correctly in some other way that's of course fine as well.