Fixing conflicts between WineD3D and WGL

[Ken Thomases]

On Jan 30, 2014, at 6:34 AM, Henri Verbeet wrote:

> On 29 January 2014 22:34, Ken Thomases <ken at codeweavers.com> wrote:
> 
>> 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.)

Well, it would be different because it wouldn't change the app's GL context to point at a potentially-different drawable.  Which, by the way, is actually happening in bug 28869.  The app does GL against a top-level window but uses ddraw/wined3d on a child window of that window.  So, your hack wouldn't work because it would make the app's GL context current on a window that's destroyed soon after.

I was investigating that bug further and discovered that it doesn't actually have anything to do with the DC having been deleted. There's a place in wined3d where it clears the GL context and doesn't save the information necessary to restore the app's GL context.  So, it just leaves the app with no current GL context so its GL calls all do nothing.  Removing that one call fixes that bug.

That bug was the main motivation for this extension.  Still, the general principle of being able to restore the GL context even after its DC was destroyed remains.

In experimenting with implementing the extension and making wined3d use it, I discovered a complication.  At the same point where wined3d attempts to restore the app's GL context, it also tries to restore the pixel format on the app's DC.  On the one hand, my extension doesn't help with that which undermines its rationale since the DC is still required.  On the other hand, that's the wrong thing for wined3d to try to do there!  Wined3d has set the pixel format on its target window (through a DC it obtained itself).  In many cases, the app will be targeting the same window with its GL context, but not always (as we've seen).  So, wined3d should be trying to restore the pixel format of the window it modified, not the window the app's GL context may be targeting.

This is a separate bug that should be fixed.  Probably, wined3d should keep track of the window on which it set the pixel format and set that window's pixel format back before returning control.  (It can use any DC for that window to do that, even one it obtains just for that purpose.)

-Ken