Fixing conflicts between WineD3D and WGL

[Chris Robinson]

On 01/29/2014 03:10 AM, Henri Verbeet wrote:
> There may be performance reasons though. The wglMakeCurrent()
> required to restore the previous GL context is pretty expensive, so
> applications that have a GL context current while calling into
> wined3d take a considerable performance hit. I think I've only ever
> seen 1 or 2 applications that were affected that though, so perhaps
> we don't care enough.

The multi-threaded command stream patches would fix this issue, wouldn't 
it? In that case, WineD3D has a GL context on its own thread to handle 
the D3D calls, leaving the app threads more or less alone. Of course, 
it'll be a while before they get into Wine proper.