Fixing conflicts between WineD3D and WGL

[Ken Thomases]

On Feb 6, 2014, at 4:19 AM, Henri Verbeet wrote:

> … 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.

I don't think it can work that way.  DC handle values get recycled pretty aggressively.  Just because the handle value is the same between point A and point B doesn't mean it references the same window.


> On 5 February 2014 20:20, Ken Thomases <ken at codeweavers.com> wrote:
> 
>> 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.

Agreed, it won't 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.

I think I have a patch for this.  It may not be ideal because it tracks the window to restore the pixel format on separately from the context window.  (In some cases, e.g. swapchain backup DC, the context window is not what the context DC references.)  I'll send it along in a bit.  I suppose I need to add a test case, too.

Anyway, I believe it's necessary to decouple restoring the pixel format from restoring the GL context, anyway, in order to use wglMakeContextCurrentWINE().

>  - 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.

Right.  I don't have a solution for that with current APIs but WGL_WINE_surface will sidestep it.

> 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.

Yeah, but, as I said, I think I need to solve the current case anyway, to the degree it can be solved.

-Ken