On 26 January 2010 13:42, Stefan Dösinger <[email protected]> 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.
