https://bugs.winehq.org/show_bug.cgi?id=52354
Bug ID: 52354 Summary: winemac.drv not functional on non metal GPUs Product: Wine Version: 6.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs@winehq.org Reporter: gcenx83@gmail.com Distribution: ---
Since wine-6.17 winemac.drv no longer functions on non Metal GPUs this breaks legacy versions of mac OS X below 10.11 and systems that contain GPUs that don't support Metal.
https://bugs.winehq.org/show_bug.cgi?id=52354
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |52216 Regression SHA1| |3f845b34deada0dd58e3674119a | |f47ce85851c24
https://bugs.winehq.org/show_bug.cgi?id=52354
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=52354
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gcenx83@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #1 from Gcenx gcenx83@gmail.com --- Created attachment 71534 --> https://bugs.winehq.org/attachment.cgi?id=71534 The results of Brendan proposed patch
Brendan proposed a patch to get winemac.drv functional again, however as can be seen it's not drawn correctly.
See https://www.winehq.org/pipermail/wine-devel/2021-December/203914.html
https://bugs.winehq.org/show_bug.cgi?id=52354
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |reinhold.hoffmann@hotmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=52354
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major OS|Linux |Mac OS X
https://bugs.winehq.org/show_bug.cgi?id=52354
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |blocker
https://bugs.winehq.org/show_bug.cgi?id=52354
Huw Davies huw.davies@physics.ox.ac.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bshanks@codeweavers.com, | |cdavis5x@gmail.com, | |huw.davies@physics.ox.ac.uk
--- Comment #2 from Huw Davies huw.davies@physics.ox.ac.uk --- Adding Chip and Brendan to the Cc list.
https://bugs.winehq.org/show_bug.cgi?id=52354 Bug 52354 depends on bug 52216, which changed state.
Bug 52216 Summary: winemac.drv fails to compile without Metal support https://bugs.winehq.org/show_bug.cgi?id=52216
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #3 from Brendan Shanks bshanks@codeweavers.com --- Interesting, with my patch (the empty drawRect) on 10.13 winecfg looks correct, not with the wrong window size like the screenshot.
Dean, if you revert 3f845b34deada0dd58e3674119af47ce85851c24, does it work correctly?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #4 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #3)
Interesting, with my patch (the empty drawRect) on 10.13 winecfg looks correct, not with the wrong window size like the screenshot.
Dean, if you revert 3f845b34deada0dd58e3674119af47ce85851c24, does it work correctly?
Reverted that commit and it didn’t help, it still works the same as shown in the provided screenshot.
The same compile works just fine on my Mojave install.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #5 from Gcenx gcenx83@gmail.com --- Created attachment 71728 --> https://bugs.winehq.org/attachment.cgi?id=71728 Working winemac.drv after reverts
After reverting the 5 commits for "winemac.drv: Enable layer-backed views.", winemac.drv is working correctly on Mac OS X 10.9.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #6 from Reinhold reinhold.hoffmann@hotmail.com --- It would be helpful if this bloking bug could be completely fixed asap as people who upgrade from previous stable versions now run into this blocker. Thanks.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #7 from Gcenx gcenx83@gmail.com --- To update.
This bug affects macOS High Sierra and below as that’s the last version of macOS that doesn’t require a Metal capable GPU.
The stub method was only confirmed to work on 10.13 (not sure about other versions as I own a Metal capable Mac), on 10.9 the stub gets winemac.drv to at least display but the window doesn’t get rendered to the window scale. Winecfg loads but when attempting to press a button it doesn’t line up with that’s drawn. (See attachment https://bugs.winehq.org/attachment.cgi?id=71534)
Reverting the 5 related commits on 10.9 resulted in fully functional winemac.drv that renders/draws correctly.
https://bugs.winehq.org/show_bug.cgi?id=52354
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yousif.seedhom@gmail.com
--- Comment #8 from Gijs Vermeulen gijsvrm@gmail.com --- *** Bug 52573 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52354
Tim Clem tclem@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tclem@codeweavers.com
--- Comment #9 from Tim Clem tclem@codeweavers.com --- Just to clarify, the original build failures were Metal related, but the rendering problems are not. I can reproduce these issues on my 2015 MacBook Pro, which supports Metal.
There are two distinct issues at play here, both of which do not happen in Mojave or later.
1. As Brendan noted in the mailing list thread, calling setNeedsDisplay: on WineContentViews doesn't trigger an updateLayer call. This is supposed to happen if the layer has a layerContentsRedrawPolicy of NSViewLayerContentsRedrawOnSetNeedsDisplay. We don't currently set that, so it must somehow work without the redraw policy on later versions of macOS. However, even with that policy set, updateLayer basically gets called once per window on High Sierra. I can work around this by making WineContentView's setNeedsDisplay: and setNeedsDisplayInRect: manually call the analogous methods on its layer. That makes the window contents draw, and reliably reveals issue #2.
2. On retina-capable screens on High Sierra, the contentsScale of WineContentView's layer is always effectively 2, regardless of Wine's settings. We set the initial contentsScale on the layer when we make WineContentViews, and we return false from -layer:shouldInheritContentsScale:fromWindow: unless retina mode is on, so this should not happen. But somehow, by the time updateLayer is called, the contentsScale is always 2. That's not a scenario that the code expects, so we wind up creating an incorrectly scaled image, and we get the misalignment shown in Dean's screenshot.
While it's relatively easy to work around issue #1, issue #2 is more persistent. The best mitigation I've come up with for that involves forcibly rendering the layer's contents at the scale implied by Wine's retina setting (rather than the layer's actual contentsScale). On retina displays that at least gets the view's contents to align correctly, but the upscaling looks horrible.
I think it makes sense to just revert the patches. I'll submit that to wine-devel.
In the long run I'm not sure that layer-backed views are the right direction, if only because updateLayer requires a complete redraw of the view vs. drawRect:'s more precise dirtyRect.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #10 from Charles Davis cdavis5x@gmail.com --- (In reply to Tim Clem from comment #9)
Just to clarify, the original build failures were Metal related, but the rendering problems are not. I can reproduce these issues on my 2015 MacBook Pro, which supports Metal.
There are two distinct issues at play here, both of which do not happen in Mojave or later.
- As Brendan noted in the mailing list thread, calling setNeedsDisplay: on
WineContentViews doesn't trigger an updateLayer call. This is supposed to happen if the layer has a layerContentsRedrawPolicy of NSViewLayerContentsRedrawOnSetNeedsDisplay. We don't currently set that, so it must somehow work without the redraw policy on later versions of macOS.
The default for a layer-backed view is NSViewLayerContentsRedrawDuringViewResize, which is a subset of NSViewLayerContentsRedrawOnSetNeedsDisplay.
However, even with that policy set, updateLayer basically gets called once per window on High Sierra. I can work around this by making WineContentView's setNeedsDisplay: and setNeedsDisplayInRect: manually call the analogous methods on its layer. That makes the window contents draw, and reliably reveals issue #2.
- On retina-capable screens on High Sierra, the contentsScale of
WineContentView's layer is always effectively 2, regardless of Wine's settings. We set the initial contentsScale on the layer when we make WineContentViews, and we return false from -layer:shouldInheritContentsScale:fromWindow: unless retina mode is on, so this should not happen. But somehow, by the time updateLayer is called, the contentsScale is always 2. That's not a scenario that the code expects, so we wind up creating an incorrectly scaled image, and we get the misalignment shown in Dean's screenshot.
According to the docs, that method's associated protocol isn't supported until 10.14. I wonder if it were broken prior to 10.14. Or maybe we shouldn't even say YES in response to the new scale being 1.0--maybe it calls the method once prior to 10.14, and caches the result. Does that help?
While it's relatively easy to work around issue #1, issue #2 is more persistent. The best mitigation I've come up with for that involves forcibly rendering the layer's contents at the scale implied by Wine's retina setting (rather than the layer's actual contentsScale). On retina displays that at least gets the view's contents to align correctly, but the upscaling looks horrible.
I think it makes sense to just revert the patches. I'll submit that to wine-devel.
In the long run I'm not sure that layer-backed views are the right direction, if only because updateLayer requires a complete redraw of the view vs. drawRect:'s more precise dirtyRect.
Apple's docs suggest that setting a bitmap into a layer is faster than drawing into it. Since we already draw into a bitmap, I thought this would be an obvious performance win.
Part of the reason I wanted to move to layer-backed views is that I wanted to use this to support drawing to other processes' windows, using the CARemoteLayer infrastructure. Without layer-backed views, how do you propose we implement drawing to other processes' windows?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #11 from Gcenx gcenx83@gmail.com --- I’m open to trying any patches to keep the current functionality but fix the issues.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #12 from Charles Davis cdavis5x@gmail.com --- (In reply to Charles Davis from comment #10)
The default for a layer-backed view is NSViewLayerContentsRedrawDuringViewResize, which is a subset of NSViewLayerContentsRedrawOnSetNeedsDisplay.
Oops, *superset.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #13 from Tim Clem tclem@codeweavers.com --- (In reply to Charles Davis from comment #10)
(In reply to Tim Clem from comment #9)
Just to clarify, the original build failures were Metal related, but the rendering problems are not. I can reproduce these issues on my 2015 MacBook Pro, which supports Metal.
There are two distinct issues at play here, both of which do not happen in Mojave or later.
- As Brendan noted in the mailing list thread, calling setNeedsDisplay: on
WineContentViews doesn't trigger an updateLayer call. This is supposed to happen if the layer has a layerContentsRedrawPolicy of NSViewLayerContentsRedrawOnSetNeedsDisplay. We don't currently set that, so it must somehow work without the redraw policy on later versions of macOS.
The default for a layer-backed view is NSViewLayerContentsRedrawDuringViewResize, which is a subset of NSViewLayerContentsRedrawOnSetNeedsDisplay.
Ah, right you are. Didn't notice that in the documentation.
However, even with that policy set, updateLayer basically gets called once per window on High Sierra. I can work around this by making WineContentView's setNeedsDisplay: and setNeedsDisplayInRect: manually call the analogous methods on its layer. That makes the window contents draw, and reliably reveals issue #2.
- On retina-capable screens on High Sierra, the contentsScale of
WineContentView's layer is always effectively 2, regardless of Wine's settings. We set the initial contentsScale on the layer when we make WineContentViews, and we return false from -layer:shouldInheritContentsScale:fromWindow: unless retina mode is on, so this should not happen. But somehow, by the time updateLayer is called, the contentsScale is always 2. That's not a scenario that the code expects, so we wind up creating an incorrectly scaled image, and we get the misalignment shown in Dean's screenshot.
According to the docs, that method's associated protocol isn't supported until 10.14. I wonder if it were broken prior to 10.14. Or maybe we shouldn't even say YES in response to the new scale being 1.0--maybe it calls the method once prior to 10.14, and caches the result. Does that help?
I get the same behavior if I just have shouldInheritContentsScale return a constant NO, or remove it entirely. It's never called with a new scale of 1 in my testing.
If I set the contentsScale according to retinaMode in updateLayer, it at least sticks between calls, but the layer still seems to render as if it's 2. The contents are upscaled and blurry.
While it's relatively easy to work around issue #1, issue #2 is more persistent. The best mitigation I've come up with for that involves forcibly rendering the layer's contents at the scale implied by Wine's retina setting (rather than the layer's actual contentsScale). On retina displays that at least gets the view's contents to align correctly, but the upscaling looks horrible.
I think it makes sense to just revert the patches. I'll submit that to wine-devel.
In the long run I'm not sure that layer-backed views are the right direction, if only because updateLayer requires a complete redraw of the view vs. drawRect:'s more precise dirtyRect.
Apple's docs suggest that setting a bitmap into a layer is faster than drawing into it. Since we already draw into a bitmap, I thought this would be an obvious performance win.
Do we have any way to test the performance impact of these sorts of changes? There were some patches on the mailing list a few weeks ago that squeezes significant gains out of the old drawRect approach in one particular app (https://www.winehq.org/pipermail/wine-devel/2022-March/211906.html), but some sort of general benchmarking tool would be useful.
Part of the reason I wanted to move to layer-backed views is that I wanted to use this to support drawing to other processes' windows, using the CARemoteLayer infrastructure. Without layer-backed views, how do you propose we implement drawing to other processes' windows?
I didn't realize that was a motivating factor for these patches. Barring remote layers, I suppose the only other route is sharing an IOSurface. I don't really know the tradeoffs between those options. I assume remote layers are simpler and probably more performant, since they're intended for exactly that scenario.
I'm not at all against the idea of using layers, but we do need some sort of working solution for High Sierra.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #14 from Gcenx gcenx83@gmail.com --- Instead of reverting the new behavior that seems to be working for macOS Mojave and later, what about restoring the old behavior for High Sierra and below?, not ideal but at least winemac.drv will again be functional.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #15 from Tim Clem tclem@codeweavers.com --- It seems like making WineContentView layer-hosting (rather than layer-backed) fixes the retina issue. That makes a certain amount of sense - the docs say that AppKit takes a "hands off" approach to hosted layers, so whatever is basically ignoring contentsScale doesn't happen in that case. A small downside of being "hands off" is that (AFAICT) layer-hosting views aren't eligible for -updateLayer. Though I suppose that's not a big deal since that wasn't working as intended High Sierra anyway.
Attached are two patches that get this going for me on High Sierra with effectively no changes on OS versions after that. On High Sierra and earlier, I manually make a CALayer for the view and set its delegate to the view itself. -setNeedsDisplayInRect on the view forwards to the layer, which eventually triggers the -displayLayer: delegate call. That just calls -updateLayer, since that's the functionality we want. On Mojave and later, we let the view make its own layer, skip the unnecessary forwarding in setNeedsDisplay, and -updateLayer is called directly.
Chip, what are you thoughts on this approach? And Dean, would you mind kicking the tires a bit? The oldest OS I have available is High Sierra, so I'm curious how this fares before that.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #16 from Tim Clem tclem@codeweavers.com --- Created attachment 72301 --> https://bugs.winehq.org/attachment.cgi?id=72301 Layer-hosting patch v1
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #17 from Gcenx gcenx83@gmail.com --- I've tried to compile wine-7.0 with this patch but winemac.drv fails.
Firstly needed to use at least MacOSX10.12.sdk due to
:info:build /opt/local/var/macports/build/_Users_gcenx_ports_x11_wine-stable/wine-stable/work/wine-wine-7.0/dlls/winemac.drv/cocoa_window.m:348:44: error: cannot find protocol declaration for 'CALayerDelegate'; did you mean 'NSDrawerDelegate'?
Even using MacOSX10.13.SDK the build winemac.drv also fails
:info:build dlls/winemac.drv/cocoa_window.m:476:37: error: sending 'CGRect' (aka 'struct CGRect') to parameter of incompatible type 'NSRect' (aka 'struct _NSRect') :info:build self = [super initWithFrame:frame]; :info:build ^~~~~ :info:build /opt/local/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:130:39: note: passing argument to parameter 'frameRect' here :info:build - (instancetype)initWithFrame:(NSRect)frameRect NS_DESIGNATED_INITIALIZER; :info:build ^ :info:build dlls/winemac.drv/cocoa_window.m:523:47: error: sending 'NSRect' (aka 'struct _NSRect') to parameter of incompatible type 'CGRect' (aka 'struct CGRect') :info:build [self.layer setNeedsDisplayInRect:[self convertRectToLayer:rect]];
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #18 from Gcenx gcenx83@gmail.com --- Created attachment 72307 --> https://bugs.winehq.org/attachment.cgi?id=72307 wine-7.0 32Bit build attempt MacOSX10.13.sdk
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #19 from Gcenx gcenx83@gmail.com --- Just incase I'd missed some change in winemac.drv also tested the patch applied to wine-7.7 also failed the same way.
Is it possible part of the patch is missing?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #20 from Charles Davis cdavis5x@gmail.com --- (In reply to Gcenx from comment #17)
I've tried to compile wine-7.0 with this patch but winemac.drv fails.
Firstly needed to use at least MacOSX10.12.sdk due to
:info:build /opt/local/var/macports/build/_Users_gcenx_ports_x11_wine-stable/wine-stable/ work/wine-wine-7.0/dlls/winemac.drv/cocoa_window.m:348:44: error: cannot find protocol declaration for 'CALayerDelegate'; did you mean 'NSDrawerDelegate'?
For macOS less than 10.13, we'll need to define the formerly-informal CALayerDelegate protocol ourselves: the formal protocol wasn't added to the SDK until then. Much like how we have to define NSViewLayerContentScaleDelegate ourselves for macOS less than 10.14.
Even using MacOSX10.13.SDK the build winemac.drv also fails
:info:build dlls/winemac.drv/cocoa_window.m:476:37: error: sending 'CGRect' (aka 'struct CGRect') to parameter of incompatible type 'NSRect' (aka 'struct _NSRect') :info:build self = [super initWithFrame:frame]; :info:build ^~~~~ :info:build /opt/local/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit. framework/Headers/NSView.h:130:39: note: passing argument to parameter 'frameRect' here :info:build - (instancetype)initWithFrame:(NSRect)frameRect NS_DESIGNATED_INITIALIZER; :info:build ^ :info:build dlls/winemac.drv/cocoa_window.m:523:47: error: sending 'NSRect' (aka 'struct _NSRect') to parameter of incompatible type 'CGRect' (aka 'struct CGRect') :info:build [self.layer setNeedsDisplayInRect:[self convertRectToLayer:rect]];
This will be a problem no matter what SDK is used. On i386, NSRect is not a typedef for CGRect.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #21 from Gcenx gcenx83@gmail.com --- (In reply to Charles Davis from comment #20)
For macOS less than 10.13, we'll need to define the formerly-informal CALayerDelegate protocol ourselves: the formal protocol wasn't added to the SDK until then. Much like how we have to define NSViewLayerContentScaleDelegate ourselves for macOS less than 10.14.
Rechecked and CALayerDelegate is available in MacOSX10.12.SDK so below 10.12 would need this.
This will be a problem no matter what SDK is used. On i386, NSRect is not a typedef for CGRect.
Makes sense.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #22 from Tim Clem tclem@codeweavers.com --- (In reply to Gcenx from comment #21)
(In reply to Charles Davis from comment #20)
For macOS less than 10.13, we'll need to define the formerly-informal CALayerDelegate protocol ourselves: the formal protocol wasn't added to the SDK until then. Much like how we have to define NSViewLayerContentScaleDelegate ourselves for macOS less than 10.14.
Rechecked and CALayerDelegate is available in MacOSX10.12.SDK so below 10.12 would need this.
Ah, ok. I'll add that.
This will be a problem no matter what SDK is used. On i386, NSRect is not a typedef for CGRect.
Makes sense.
Yikes, sorry, that's my fault. That should definitely be an NSRect. I'll upload another version shortly, and try a 32-bit build locally.
Thanks for testing!
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #23 from Brendan Shanks bshanks@codeweavers.com --- I tested 64-bit on 10.13 (with the command line tools/10.14 SDK), and 10.11 (after removing the CALayerDelegate reference), both seemed to be working normally
https://bugs.winehq.org/show_bug.cgi?id=52354
Tim Clem tclem@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #72301|0 |1 is obsolete| |
--- Comment #24 from Tim Clem tclem@codeweavers.com --- Created attachment 72319 --> https://bugs.winehq.org/attachment.cgi?id=72319 Layer hosting patch v2
Here's an updated version that fixes the NSRect issues and declares CALayerDelegate if needed. Building and running for me on High Sierra i386.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #25 from Brendan Shanks bshanks@codeweavers.com --- I tried v2 on 10.11, both 64- and 32-bit built and ran without problems
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #26 from Gcenx gcenx83@gmail.com --- Tested building on 10.9 using MacOSX10.11.SDK and v2 gets winecfg to load correctly.
Currently don’t have the time to test out any games.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #27 from Gcenx gcenx83@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #28 from Charles Davis cdavis5x@gmail.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #29 from Gcenx gcenx83@gmail.com --- (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+?
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.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #31 from Gcenx gcenx83@gmail.com --- (In reply to Charles Davis from comment #30)
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.
While that sounds like a much better solution how long would this take you?
If this will take a lot of time and effort it would make sense for the short term to lock thenew behavior behind version check so we’ll at least have something functional for everyone without needing to do reverts for 10.13 and below.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #32 from Charles Davis cdavis5x@gmail.com --- (In reply to Gcenx from comment #31)
While that sounds like a much better solution how long would this take you?
Probably a couple of months.
If this will take a lot of time and effort it would make sense for the short term to lock thenew behavior behind version check so we’ll at least have something functional for everyone without needing to do reverts for 10.13 and below.
There's one other possibility, that I just recently thought of: do something similar to what we do for Metal right now, and put OpenGL rendering into a subview.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #33 from Gcenx gcenx83@gmail.com --- (In reply to Charles Davis from comment #32)
Probably a couple of months.
Figure that would be the case.
There's one other possibility, that I just recently thought of: do something similar to what we do for Metal right now, and put OpenGL rendering into a subview.
Maybe it’s worth first trying this option as I’m guessing this would be quicker than the above.
https://bugs.winehq.org/show_bug.cgi?id=52354
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lincoln.muller@icloud.com
--- Comment #34 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 52955 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #35 from Tim Clem tclem@codeweavers.com --- Chip, how do you feel about reverting those layer-backed view commits for now, until your changes are complete? It would be nice to have things working out of the box on High Sierra.
https://bugs.winehq.org/show_bug.cgi?id=52354
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #36 from Fabian Maurer dark.shadow4@web.de --- Any news on this? This seems important...
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #37 from Brendan Shanks bshanks@codeweavers.com --- I took a fresh look at this and...it's the preloader. Specifically, when the Wine loader binary is an LC_MAIN binary (what you get when targeting 10.8 or later), and it's loaded by the preloader, layers aren't refreshed correctly. If you build the loader targeting 10.7 (and get an LC_UNIXTHREAD binary), it works!
I'm pretty sure this is due to LC_UNIXTHREAD vs. LC_MAIN, and not the actual SDK version. I've built the loader targeting 10.14 (so LC_MAIN) and then used the 'vtool' command included with Xcode 11+ (run with 'xcrun vtool') to set the minimum version to 10.7, and it's still broken.
I'll post a very simple Wine patch that just builds the loader with '-mmacosx-version-min=10.7' when the preloader is being used, I still haven't tried it on a 10.13 retina Mac or anything earlier than 10.13. Also, I'll post a standalone test app to reproduce it.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #38 from Brendan Shanks bshanks@codeweavers.com --- Created attachment 73433 --> https://bugs.winehq.org/attachment.cgi?id=73433 Proposed patch
https://bugs.winehq.org/show_bug.cgi?id=52354
Brendan Shanks bshanks@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73433|0 |1 is obsolete| |
--- Comment #39 from Brendan Shanks bshanks@codeweavers.com --- Created attachment 73434 --> https://bugs.winehq.org/attachment.cgi?id=73434 Proposed patch (v2)
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #40 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #39)
Created attachment 73434 [details] Proposed patch (v2)
Did you test any games?
I tested this on OS X 10.9, winecfg/explorer and iexplorer all worked. However attempting to launch MDK2 windowed mode just shows the title bar, fullscreen it just a black screen.
Also tried Diablo2, managed to launch that in windowed mode (1.14c)
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #41 from Gcenx gcenx83@gmail.com --- Failed to mention this was wine-7.20
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #42 from Brendan Shanks bshanks@codeweavers.com --- No I didn't try any games, this is original MDK 2 from GOG or Steam? Does it work correctly on newer OSes and/or older Wine versions?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #43 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #42)
No I didn't try any games, this is original MDK 2 from GOG or Steam? Does it work correctly on newer OSes and/or older Wine versions?
MDK 2 from GOG, this game worked with the prior wine-7.20 built on OS X 10.9 with the winemac.drv reverts. However 10.9 is extremely old if your able to play games on 10.13.
Some games I’d recommend testing: Skyrim LE, Total Annihilation, Lego Star Wars: The Complete Saga & MDK 2 (windowed) I’d usually also include Diablo2 but the above are all on Steam.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #44 from Brendan Shanks bshanks@codeweavers.com --- I installed 10.13 on my retina MBP, tried MDK2 from GoG and was able to run it windowed correctly using the latest Wine.
Have you tried 10.13, or just 10.9?
Also BTW, when you're running on 10.9, are you building against the 10.10 SDK?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #45 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #44)
I installed 10.13 on my retina MBP, tried MDK2 from GoG and was able to run it windowed correctly using the latest Wine.
Have you tried 10.13, or just 10.9?
Also BTW, when you're running on 10.9, are you building against the 10.10 SDK?
Only tested on 10.9, I don't have any spare SSDs to test other versions.
Built against the 10.11 SDK plus macports-legacy-support (statically linked for fstatat and other missing functions)
Using LLVM/CLANG-14 with CCTOOLS-973.0.1/LD64-609
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #46 from Brendan Shanks bshanks@codeweavers.com --- I also tested MDK2 on 10.11, windowed and full-screen mode seem to work fine.
I'm going to submit this patch upstream, it seems like a clear improvement over the current (broken) upstream state and we can address other issues separately.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #47 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #46)
I also tested MDK2 on 10.11, windowed and full-screen mode seem to work fine.
I'm going to submit this patch upstream, it seems like a clear improvement over the current (broken) upstream state and we can address other issues separately.
Sounds good to me, once committed I’ll pull that into https://github.com/Gcenx/macports-wine then only have the reverts apply for anything below 10.11.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #48 from Brendan Shanks bshanks@codeweavers.com --- The fix is now upstream as 63bf2677ed22d26ff1f5ff1886fde08b1f5fb00c.
Also, I tested MDK2 on 10.9 and was able to reproduce the problem. I'm not sure what's wrong, there were some OpenGL errors printed but I'm not sure if that's the cause or just a symptom. I also tested on 10.10, and it worked correctly there.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #49 from Fabian Maurer dark.shadow4@web.de --- Gcenx, would you mind confirming before I close?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #50 from Gcenx gcenx83@gmail.com --- (In reply to Fabian Maurer from comment #49)
Gcenx, would you mind confirming before I close?
I can only test on 10.9, 10.14 & 13 at this time.
We already known this isn’t fully resolved on 10.9 so it also won’t be resolved in 10.8 but that could be something with OpenGL going off what Brendan said above.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #51 from Brendan Shanks bshanks@codeweavers.com --- The fix (63bf2677ed22d26ff1f5ff1886fde08b1f5fb00c) for this bug ended up causing crashes on macOS Monterey and Ventura, and I created bug 54009 to track that.
Also, I'm pushing my standalone test app to https://gitlab.winehq.org/bshanks/mac-preloader-testbed for experimenting with the preloader and layer-backed views.
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #52 from Brendan Shanks bshanks@codeweavers.com --- Gcenx, I created bug 54327 to track MDK2 not working on 10.9, can this bug be closed?
https://bugs.winehq.org/show_bug.cgi?id=52354
--- Comment #53 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #52)
Gcenx, I created bug 54327 to track MDK2 not working on 10.9, can this bug be closed?
Brendan, yeah probably best to close this and follow up in the new bug.
https://bugs.winehq.org/show_bug.cgi?id=52354
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #54 from Gijs Vermeulen gijsvrm@gmail.com --- Let's call this one FIXED, thanks everyone for getting this done.
https://bugs.winehq.org/show_bug.cgi?id=52354
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |63bf2677ed22d26ff1f5ff1886f | |de08b1f5fb00c
https://bugs.winehq.org/show_bug.cgi?id=52354
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #55 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.1.
-
WineHQ Bugzilla