Fixing conflicts between WineD3D and WGL

[Henri Verbeet]

On 5 February 2014 20:20, Ken Thomases <ken at codeweavers.com> wrote:
>> 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.
>
Actually, what confused me there was thinking of the current DC as
thread state as opposed to context state. So yeah,
wglMakeContextCurrentWINE() should work. It does have me wondering
slightly if wglMakeCurrent() shouldn't behave like that anyway if the
DC it gets passes is the same as the one the context was last current
with, but perhaps not enough to go find out.

> 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.
>
It may not be enough in some cases, and redundant in others, but I
don't think it's wrong as such. I.e., if the wined3d GL DC and the
application's GL DC aren't the same, restoring the pixel format on the
application's GL DC is redundant because we didn't touch it, but it
should never restore the wrong pixel format. There are two cases where
it wouldn't be enough:
  - The application has set a pixel format on the wined3d DC before,
is not currently using GL on that DC, but will do so (again) in the
future. I think this case can be fixed, although it's not entirely
trivial because of e.g. context_update_window(), and IMO a bit of a
rare case.
  - The application has never set a pixel format on the wined3d DC,
but will try to do so in the future. I don't think we can fix this
with the current WGL_WINE_pixel_format_passthrough implementation. As
soon as wined3d sets a pixel format, it becomes impossible for the
application to do so in the future. This is essentially bug 29934.

In theory this entire issue should go away with wglGetSurfaceDCWINE()
though, because in that case we'd never have to restore the pixel
format at all, provided there's no way the application can get at the
same DC wined3d is using.