https://bugs.winehq.org/show_bug.cgi?id=2082
--- Comment #140 from Ken Thomases ken@codeweavers.com --- If we're reasonably sure that there's always a meaningful device window, then we can change the extension to just provide a function:
BOOL wglEnableFullScreenWINE(HDC hdc, BOOL enable);
WineD3D would continue to use GetDC() to get the window's DC, but for full-screen it would use the above function to tell the driver to use the full-screen behavior. In wined3d_release_dc(), it would disable full-screen to reset the DC back to normal. (Since DCs are cached, the full-screen state would otherwise leak through to the next caller to reuse that DC.)
In the drivers, tracking the pixel format would proceed as normal. It would be associated with the DC's window and could normally only be set once. (Or do we have a need for tracking the pixel format separately to avoid "contaminating" the window? If so, we could do that.)
(In reply to comment #139)
A somewhat related issue is that for applications using OpenGL, the DC is visible through wglGetCurrentDC(). I don't know if that will necessarily break anything, but I wouldn't be terribly surprised if it did.
Hmm. It seems quite unlikely that an app would call that while one of WineD3D's contexts was current. And if it did, what could it expect to be true about the returned DC? I guess it could assume it's a window DC and go astray. Anyway, with this altered proposal the DC would be the same as the current code, although it would be marked for full-screen behavior for OpenGL.
Also slightly related to this bug are bug 29301 and bug 30062.
For bug 29301, using the proposed full-screen rendering mode in the driver would allow WineD3D to not muck with the window styles. The existing patches didn't make that change but it can certainly be done.
I didn't understand the issue in bug 30062 well enough to know how it relates.