[2/5] WineD3D: Add an internal event query finish function

Stefan Dösinger stefandoesinger at gmx.at
Tue Jan 26 06:42:04 CST 2010

Am 26.01.2010 um 12:44 schrieb Henri Verbeet:

> On 26 January 2010 11:51, Stefan Dösinger <stefan at codeweavers.com> wrote:
>> +HRESULT wined3d_event_query_finish(IWineD3DQuery* iface) {
> Please don't create function prototypes (or other code) by copy/paste.
> Also, why does this take a IWineD3DQuery pointer in the first place?
> You only really access wined3d_event_query fields.
To avoid that the buffer code has to look inside IWineD3DQueryImpl *
See below about creating a wined3d_event_query directly.

>> +        /* A glFinish does not reliably wait for draws in other contexts. The caller has
>> +         * to find its own way to cope with the thread switch
>> +         */
> ...
>> +        /* Since this is an internal call the caller should know that event Query support is faked */
>> +        FIXME("(%p): Event query not supported, calling glFinish\n", This);
>> +        wglFinish();
>> +        return WINED3D_OK;
>> +    }
> This is inconsistent.

>> +    if (!gl_info->supported[APPLE_FENCE] && !gl_info->supported[NV_FENCE] && gl_info->supported[ARB_SYNC])
> This doesn't make sense. Of course if you just used
> wined3d_event_query instead of IWineD3DQuery you wouldn't even need
> this at all, you could just let context_alloc_event_query() fail.
I see there's a ! missing before the ARB_SYNC, but I guess your point is the entire line.

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?

More information about the wine-devel mailing list