On 5 February 2014 20:20, Ken Thomases ken@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.