Fixing conflicts between WineD3D and WGL

[Henri Verbeet]

On 29 January 2014 22:34, Ken Thomases <ken at codeweavers.com> wrote:
> My point is that the current GL context is exposed through WGL but it also affects the behavior of GL functions (of course).  So, while we might be able to hide the change of the current GL context from wglGetCurrentContext(), that doesn't do us any good because we need GL functions to target the right context.  There's just no getting around switching the current GL context to WineD3D's when WineD3D needs to call GL functions and then back to the app's when control is returned to it.  (Except Chris's point of doing all GL on a different thread.)
>
> Do you know what makes wglMakeCurrent() expensive?  For X11, we'll still have to use glXMakeCurrent(), which sets the context drawable, even for my proposed wglMakeContextCurrentWINE().  Maybe it's the setting of the drawable that's expensive.  For the Mac, we can just make the context current without setting the drawable again.  That might be less expensive, although maybe there's a lot of thread state inside the GL engine that has to be swapped in and out.  (I would hope that that would all be stored in the context and switching contexts would be just a matter of swapping a pointer somewhere.)
>
I'm not sure. I have the impression most of the time is inside the
driver instead of e.g. winex11 though.

>> Maybe. Note that some of the quirk detection code renders to this
>> context. I think all rendering there goes to FBOs, so in that regard
>> it's probably safe, but it does feel a bit fragile. For regular
>> wined3d rendering we do of course need a drawable, although this may
>> work out in practice.
>
> I'm not sure I understand.  "quirk detection code renders to this context" – to which context do you refer?
>
The one created by wined3d_caps_gl_ctx_create(). Quirk detection code
like match_broken_arb_fog() uses that context for rendering. (But only
ever renders to a FBO.)

> The point of this extension is just for restoring the app's GL context.  It would not necessarily be used to make a WineD3D context current, it would only be used to restore the app's WGL context to be current.  It doesn't take a DC so that this works even for the case where the original DC was destroyed/released.
>
Right. I was under the impression it would be used by
wined3d_caps_gl_ctx_create() to avoid changing the current WGL DC. If
it's only for restoring the application's GL context, I'm not sure how
that's effectively much different from just making the application's
GL context current on wined3d's DC? (I'd have to look into the details
again, but IIRC that wasn't enough for bug 28869, even as a hack.)