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.