https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #30 from Charles Davis cdavis5x@gmail.com --- (In reply to Gcenx from comment #29)
(In reply to Charles Davis from comment #28)
(In reply to Gcenx from comment #27)
Gotten chance to try playing some games it’s a bust for anything fullscreen.
Total Annihilation black screen, forcing windows mode works
Red Alert2 back screen when fullscreen, also tried cnc-ddraw it loaded the menu but after selecting skirmish nothing until I try to load the menu. The menu to exit loaded but not the actual game.
So seems there’s still work to be done.
/me facepalms
*Now* I remember. I tried using layer-hosting views everywhere at first, but it didn't work right with OpenGL--the GL surface doesn't get created properly or something. Using layer-backed views made it work again.
So does that mean falling back to the older functionally for 10.13 and below and using the newer backend on 10.14+?
Possibly.
Another possibility is simply removing the layer from the view at wglMakeCurrent() time. Though I don't know how well removing the hosted layer once set would work. And if the process draws with both GDI and GL...
The other possibility--which we will need for cross-process GL--is setting up a layer as the default GL drawable. While there is a CAOpenGLLayer, it has several restrictions that make it unsuitable for our use: in particular, it does all GL context and drawable management itself, so you can only draw in its -drawInCGLContext:pixelFormat:forLayerTime:displayTime: method.
We'll have to implement our own OpenGLLayer, using IOSurfaces as the drawables, with hooks in glDrawBuffer[s]() to redirect handling of the built-in framebuffer to our IOSurfaces. This will be very complicated, and I'm not looking forward to this. Ah, who am I kidding? I'm totally looking forward to this. I like a good challenge.