http://bugs.winehq.org/show_bug.cgi?id=34166
Bug #: 34166 Summary: Fullscreen flickering on Mac Product: Wine Version: 1.6-rc5 Platform: x86-64 OS/Version: Mac OS X Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: M8R-45axwd@mailinator.com Classification: Unclassified
The fullscreen flickering bug-- http://bugs.winehq.org/show_bug.cgi?id=29261 --was fixed by the introduction of the mac driver, and in Wine 1.6 RC4 everything works fine. However, the flickering is back in 1.6 RC5 even WITH the mac driver. The problem is still present in stable Wine 1.6.
I'll try to do a regression test for this bug, but it seems like a hard thing to do. Maybe somebody will be able to identify the cause quicker than me.
OS X 10.7.5, ATI Radeon HD 2600 Pro 256 MB
http://bugs.winehq.org/show_bug.cgi?id=34166
DSIAID05FRhkpBPM M8R-45axwd@mailinator.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.winehq.org/show | |_bug.cgi?id=29261
http://bugs.winehq.org/show_bug.cgi?id=34166
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=34166
thanoulas thanoulas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thanoulas@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34166
thanoulas thanoulas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #1 from thanoulas thanoulas@gmail.com 2013-07-30 17:27:51 CDT --- d30705bdfe1756aa9ac9102a293d96a05afec7b0 is the first bad commit commit d30705bdfe1756aa9ac9102a293d96a05afec7b0 Author: Ken Thomases ken@codeweavers.com Date: Tue Jul 2 01:24:19 2013 -0500
winemac: Use screen color space for windows covered by OpenGL views.
:040000 040000 c68a36b0f6fbe1135dd9d175d9d536ed843c62a6 f04e28079de21a1f30af7b84f098c1ada956731b M dlls
This is the commit that breaks winemac.drv
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #2 from thanoulas thanoulas@gmail.com 2013-07-30 17:27:58 CDT --- d30705bdfe1756aa9ac9102a293d96a05afec7b0 is the first bad commit commit d30705bdfe1756aa9ac9102a293d96a05afec7b0 Author: Ken Thomases ken@codeweavers.com Date: Tue Jul 2 01:24:19 2013 -0500
winemac: Use screen color space for windows covered by OpenGL views.
:040000 040000 c68a36b0f6fbe1135dd9d175d9d536ed843c62a6 f04e28079de21a1f30af7b84f098c1ada956731b M dlls
This is the commit that breaks winemac.drv
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #3 from thanoulas thanoulas@gmail.com 2013-07-30 17:59:27 CDT --- Reversing the commit on latest from git, fixes the flickering
http://bugs.winehq.org/show_bug.cgi?id=34166
DSIAID05FRhkpBPM M8R-45axwd@mailinator.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d30705bdfe1756aa9ac9102a293 | |d96a05afec7b0
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #4 from Ken Thomases ken@codeweavers.com 2013-07-30 18:20:00 CDT --- I had a sneaking suspicion that that's what it would be.
Short version: as discussed in bug 29261, this is a bug in Apple's OpenGL. WineD3D could work around it, but Henri is disinclined to do that.
Long version:
Here's the thing, for some games, WineD3D does something a bit unusual: in circumstances where it's only really interested in using one buffer, it nevertheless creates a double-buffered context. It then only draws to the front buffer and ignores the back buffer.
This interacts poorly with the assumptions made in Apple's OpenGL optimizations. Those optimizations assume that, for a double-buffered context, the app will be drawing to the back buffer and swapping it to display it.
The result is that, for each frame, Apple's OpenGL is replacing the good drawing done by WineD3D with the garbage in the uninitialized back buffer. This is the cause of the horrible flickering.
What WineD3D is doing is unusual but legal. Apple's OpenGL optimization is therefore buggy.
The Mac driver, prior to commit d30705bd, was unintentionally doing something that was defeating optimizations in Apple's OpenGL. The one good effect of that was that it prevented the bad optimization from kicking in and causing the flickering. The obvious bad effect is that it negatively impacted performance of OpenGL graphics.
Commit d30705bd fixed this problem in the Mac driver, allowing Apple's OpenGL optimizations to take effect. In most cases, this is good. For those particular games which use this one-buffer-of-a-double-buffered-context technique, it also re-enables the optimization that causes the flickering. That's unfortunate, but not really the fault of the Mac driver.
WineD3D could change the way it operates to work around this bug in Apple's OpenGL. That's out of my area.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #5 from thanoulas thanoulas@gmail.com 2013-07-31 12:52:05 CDT --- I highly doubt that apple would ever fix this, as (per your description) wined3d provides two buffers to opengl when it should only provide one. So I guess this should be fixed in wined3d, or at least have a registry value where someone could disable the effects of this commit?
http://bugs.winehq.org/show_bug.cgi?id=34166
doh123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |doh123@gmail.com
--- Comment #6 from doh123@gmail.com 2013-07-31 13:19:40 CDT --- I mean no offense, but it really sounds like lazy programming in the Wine side to always use a double buffered context even when its not needed... This really should be fixed in Wine, regardless of how Apple's OpenGL works. Legally correct or not isn't the point... there are a TON of bad coding practices that are legally correct, so that statement never goes right with me. I wouldn't really expect Apple to change this.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2013-07-31 13:24:47 CDT --- (In reply to comment #6)
I mean no offense, but it really sounds like lazy programming in the Wine side to always use a double buffered context even when its not needed...
Yeah, I mean no offense either, but you really have no idea what you're talking about. Either way, this is pretty much a duplicate of the earlier mentioned bug 29261.
http://bugs.winehq.org/show_bug.cgi?id=34166
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #8 from thanoulas thanoulas@gmail.com 2013-10-14 18:21:38 CDT --- Still present in 1.7.4 Tested more games and here's some that are affected: Baldur's Gate Baldur's Gate 2 Icewind Dale Icewind Dale 2 Planescape Torment (They all basically use the same engine)
Furthermore, reversing the offending commit in 1.7.4 results in freezing after a while (everything is displayed correctly for about 1 minute or so, and then the whole system freezes) Are we still hoping for an Apple fix? Can anyone test this issue on Mavericks, see if it's still present?
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #9 from WineBuG winebugs140@gmail.com 2013-10-15 08:11:58 CDT --- Maybe we should try to report it to Apple first? Link: bugreport.apple.com
Possibly a Wine developer could do that, one who would be able to describe the problem well in technical terms.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #10 from Linus Unnebäck linus@folkdatorn.se 2013-10-23 18:51:37 CDT --- Created attachment 46394 --> http://bugs.winehq.org/attachment.cgi?id=46394 Patch for reverting bug-introducing commit
This is a patch against 1.7.4 which makes fullscreen work without flickering, I have tested and verified that it works myself.
http://bugs.winehq.org/show_bug.cgi?id=34166
Linus Unnebäck linus@folkdatorn.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linus@folkdatorn.se
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #11 from WineBuG winebugs140@gmail.com 2013-10-26 15:23:53 CDT --- The problem is not fixed on OS X 10.9 Mavericks.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #12 from WineBuG winebugs140@gmail.com 2013-10-29 09:09:01 CDT --- This is the answer I've got from Apple regarding this bug: "Engineering has determined that this is an issue for you to resolve. One must render to the back buffer as rendering to the front buffer results in undefined swapping behavior."
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #13 from Henri Verbeet hverbeet@gmail.com 2013-10-29 09:28:44 CDT --- It sounds like they don't understand the bug. We're not swapping buffers when rendering to the front buffer.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #14 from WineBuG winebugs140@gmail.com 2013-10-29 11:11:54 CDT --- (In reply to comment #13)
It sounds like they don't understand the bug. We're not swapping buffers when rendering to the front buffer.
Maybe if would provide me with more info on the nature of this bug, I could then attach it to my bug report on Apple Bugreporter.
I'm not a programmer myself, but I'm doing my best to make sure that Apple knows about the issue.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #15 from WineBuG winebugs140@gmail.com --- (In reply to comment #13)
Now Apple is asking me this: "Are you rendering to the front buffer but expect it to be defined?"
Please Henri, provide here more info, I will attach it then to my bug report at http://bugreport.apple.com/, and maybe finally Apple will fix this flickering.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #16 from WineBuG winebugs140@gmail.com --- (In reply to comment #13) Or you can create at Apple Bug Reporter your own flickering bug report explaining everything to Apple. Here's the number of my bug report, so that you can refer to it: 15282465
http://bugs.winehq.org/show_bug.cgi?id=34166
Dr 4asm ignas2526@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ignas2526@gmail.com
--- Comment #17 from Dr 4asm ignas2526@gmail.com --- I have this issue too with Cossacks Back To War. Game runs fine, except for crazy flickering and top of the screen, about 1/5 of the screen, pretty much always remaining white or black.
I also was playing one flash game, which was working perfectly, but as soon as I entered full screen, it started flashing with white as crazy.
Macports Wine 1.7.11, Mac Os X 10.9 Mavericks
http://bugs.winehq.org/show_bug.cgi?id=34166
A.Steinel A.Steinel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |A.Steinel@gmail.com
--- Comment #18 from A.Steinel A.Steinel@gmail.com --- I created a patch based on the patch from Linus Unnebäck (Tack så mycket Linus) for 1.7.11. Please feel free to try it at
https://raw2.github.com/lnxbil/WineskinEngines/master/wine-1.7.11-OSXPatchWi...
BTW: There is also a prebuilt Wineskin engine which works for me.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #19 from Dr 4asm ignas2526@gmail.com --- I forgot to mention, when I've set registry key DirectDrawRenderer to gdi, flickering had stopped.
http://bugs.winehq.org/show_bug.cgi?id=34166
Lebostein lebostein@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lebostein@gmx.de
--- Comment #20 from Lebostein lebostein@gmx.de --- This horrible, never ending story of a bug is the only reason why I do not use Wine on the Mac! Is there no one who can implement is a reasonable solution? This bug has been known for over 3 years now. The programmers of Wine say: "The fault lies with Apple." Apple says: "The programmers of Wine have not implemented correctly." ???
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #21 from Lebostein lebostein@gmx.de --- (In reply to comment #18)
I created a patch based on the patch from Linus Unnebäck (Tack så mycket Linus) for 1.7.11. Please feel free to try it at
https://raw2.github.com/lnxbil/WineskinEngines/master/wine-1.7.11- OSXPatchWine.diff
BTW: There is also a prebuilt Wineskin engine which works for me.
Hm. Thanks. This goes in the right direction. If you start a fullscreen application with the user engine above (I have tested "Age of Wonders 2") then it flickers as usual. But if I press Command-Tab then the application switch in a pseudo fullscreen mode. In this mode I can see the Mac OS menu bar at the top of the screen an I can roll out the Mac OS icon bar at the bottom of the screen. But the rest of the screen is filled by the game itself. You can play as normal and nothing flickers. Very interesting....
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #22 from Lebostein lebostein@gmx.de --- (In reply to comment #18)
I created a patch based on the patch from Linus Unnebäck (Tack så mycket Linus) for 1.7.11. Please feel free to try it at
https://raw2.github.com/lnxbil/WineskinEngines/master/wine-1.7.11- OSXPatchWine.diff
BTW: There is also a prebuilt Wineskin engine which works for me.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! OK! It works! I still can not believe it! Fullscreen + activated Direct3D = No Flicker! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is my Test-Configuration:
MacBook Pro Mid 2009 8 GB 1067 MHz DDR3 NVIDIA GeForce 9400M 256 MB Display 1280 x 800 Mac OS X 10.9.1
Engine: WS9Wine1.7.11NoFlicker (by A.Steinel) Wrapper: Wineskin-2.5.12 Configuration: Default (no winetricks) + "Use Mac Driver instead of X11" in Screen Options
Game: http://www.gog.com/game/age_of_wonders_shadow_magic
Screenshot game setup: https://dl.dropboxusercontent.com/u/13472834/aow_sm_setup.png
Screenshot game: https://dl.dropboxusercontent.com/u/13472834/aow_sm_game.png
You can see in the game screenshot the smooth transition between the hidden world and the visible area. This smooth transition is only visible when Direct3D is enabled. Look at the other screenshots from the Linux users (right one): http://appdb.winehq.org/screenshots.php?iAppId=2190&iVersionId= Here you can see a sharp transition between the fog and the visible world. Direct3D is off in this case. These players have to give up all graphic effects like fire, fog and so on.
The people in charge of Wine should reconsider their position. It is possible to fix this bug, without Apple.
Thanks!
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #23 from Henri Verbeet hverbeet@gmail.com --- Created attachment 47352 --> http://bugs.winehq.org/attachment.cgi?id=47352 hack
Well, if you want to use hacks, the attached should probably do.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #24 from A.Steinel A.Steinel@gmail.com --- (In reply to comment #22)
The people in charge of Wine should reconsider their position. It is possible to fix this bug, without Apple.
Good to hear that it works, but the anti-flicker patch is still a workaround. It disables optimized rendering and therefore performance is decreased.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #25 from Henri Verbeet hverbeet@gmail.com --- (In reply to comment #15)
(In reply to comment #13)
Now Apple is asking me this: "Are you rendering to the front buffer but expect it to be defined?"
Well yes, I don't think rendering to the front buffer is somehow inherently unreasonable. (Or why even bother providing single buffered contexts?) I think Ken explained the issue pretty well in comment 4, but here's another try:
For the affected applications, we have a double buffered GL context, but only ever render to the front buffer. For some reason the (uninitialized) contents of the back buffer get copied to the front buffer without us calling [NSOpenGLContext flushBuffer] / CGLFlushDrawable(). This seems to only happen while in fullscreen mode.
For good measure I'll also explicitly mention that we're not reading from the front buffer and expecting any particular result, expecting the back buffer contents to be defined after a buffer swap, or anything silly like that, and that this all works fine on every single other OpenGL implementation we're aware of, including MacOS versions before Lion.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #26 from A.Steinel A.Steinel@gmail.com --- (In reply to comment #23)
Created attachment 47352 [details] hack
Well, if you want to use hacks, the attached should probably do.
Thank you Henry for this patch. I created a new Wineskin engine and compared the performance for your patch with the reverted patch by Linus (which back introduced the unoptimized behavior but stop flickering) and also vanilla 1.7.11.
At first, both patch attempts resolve the flickering issue (at least for me). I benchmarked it against 'CrystalMark 2004R3' Direct2D test and got (of course) higher frame rates out of your hack than the reverting-patch version. The benchmark can be view here:
https://github.com/lnxbil/WineskinEngines/tree/master/Benchmark-1.7.11
If anyone has a proper benchmark tool, feel free to post your results. I think CrystalMark served its demonstration purpose, yet not more.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #27 from Lebostein lebostein@gmx.de --- Why in your benchmark results the framerate is capped by 60 Hz (Vanilla) and 30 Hz (Unnerbäck)? Is that a VSync behaviour? An why the framerate of Verbeet is not capped? In the range of not capped values the framerate seems to be the same for all... I see no difference between these results.
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #28 from A.Steinel A.Steinel@gmail.com --- (In reply to comment #27)
Why in your benchmark results the framerate is capped by 60 Hz (Vanilla) and 30 Hz (Unnerbäck)? Is that a VSync behaviour? An why the framerate of Verbeet is not capped?
I have no idea. Nothing else than the applied patch. I expected different rendering times, yet nothing so drastic and unbelievable. Feel free to do your own benchmark, yet please report back.
In the range of not capped values the framerate seems to be the same for all... I see no difference between these results.
It's true, the differences are maginal, but they're there.
http://bugs.winehq.org/show_bug.cgi?id=34166
Linus Unnebäck linus@folkdatorn.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46394|0 |1 is obsolete| |
--- Comment #29 from Linus Unnebäck linus@folkdatorn.se --- Created attachment 47639 --> http://bugs.winehq.org/attachment.cgi?id=47639 Patch for reverting bug-introducing commit (wine-1.7.13)
Here is an updated version of the patch, modified to work against wine 1.7.13. I just tested it with the homebrew version of wine.
http://bugs.winehq.org/show_bug.cgi?id=34166
Johan Gardhage johan.gardhage@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #30 from Dr 4asm ignas2526@gmail.com --- Still an issue in Wine 1.7.14 also an issue in 3DMark 2000
http://bugs.winehq.org/show_bug.cgi?id=34166
xChris csynt@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |csynt@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=34166
Andrew Fan andrewsuicune@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewsuicune@gmail.com
--- Comment #31 from Andrew Fan andrewsuicune@gmail.com --- I was wondering why Touhou 14 and 14.3 were spazzing between white, black, and my desktop before loading in fullscreen. I assume this bug is the cause? If so, then this is present in 1.7.26
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #32 from Andrew Fan andrewsuicune@gmail.com --- err:display:macdrv_ChangeDisplaySettingsEx No matching mode found 1920x1200x32 @0!
^This is what I am getting during the fullscreen spaz. I hope it helps.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #33 from Ken Thomases ken@codeweavers.com --- No, that's a different issue. Please file a new bug report for that.
https://bugs.winehq.org/show_bug.cgi?id=34166
Josh Pettus jshpettus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jshpettus@gmail.com
--- Comment #34 from Josh Pettus jshpettus@gmail.com --- Still in 10.10.2 this is an issue
Here is the thing...As soon as 3rd party software is mentioned in the bug report of course Apple is going to say take it up with the 3rd party developers. If there were many other 3rd party developers affected by this issue, then they would look into it. But the fact is there isn't. At least none that I know of. So what do we do? Stoically take the bug on the chin till rapture?
Can multiple programers who fully understands the issue file reports with Apple without even mentioning wine? Really make the case that it's an OSX bug. This is probably a time when not being vague is actually hurting our case.
To be honest I really don't understand why we don't just use the hack. Yes its a hack. But hacks can be taken out down the road every bit as easily as they can be implemented. Must we really suffer while we wait for the true fix? Does the hack have any negative effects? It has been implemented in crossover for years now. Has there been customer feedback with issues? To me putting questionable coding in the paid software would be the worse ofense, but it was deemed ok.
https://bugs.winehq.org/show_bug.cgi?id=34166
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #35 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Linus Unnebäck from comment #29)
Created attachment 47639 [details] Patch for reverting bug-introducing commit (wine-1.7.13)
Here is an updated version of the patch, modified to work against wine 1.7.13. I just tested it with the homebrew version of wine.
Thank you for the patch. I confirm that it is usefull for wine-1.7.40 and affected applications 3DMark2001 and 3DMark03. Without this patch I have messy screen on start. With this patch the screen is black with the logo.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #36 from Linus Unnebäck linus@folkdatorn.se --- I've added those to the list of affected apps, thank you.
https://bugs.winehq.org/show_bug.cgi?id=34166
xChris csynt@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|csynt@hotmail.com |
https://bugs.winehq.org/show_bug.cgi?id=34166
Sam sam.h.russell@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sam.h.russell@gmail.com
--- Comment #37 from Sam sam.h.russell@gmail.com --- tl;dr I am experiencing this issue on OSX when building from source, but the Homebrew package for Wine 1.7.51 uses above patch so homebrew users should not be affected
I have been experiencing this bug with Black and White 1.0.
[sorry if this seems unrelated, I promise it is useful data though]
- I tried running Black and White with the Homebrew install of wine https://github.com/Homebrew/homebrew/blob/ae00212982f61f5e358c500f108e837f73... - This gave me issues with textures - I then built wine myself from HEAD, using the patches at https://appdb.winehq.org/objectManager.php?sClass=version&iId=13502 - This fixed the textures, but I had the flickering issue - On further inspection, it appears that Homebrew Wine 1.7.51 pulls this patch https://github.com/Homebrew/homebrew/blob/ae00212982f61f5e358c500f108e837f73... - I am now building Wine 1.7.51 with all 3 patches, will post results both here and on the Black & White page
System: Macbook Air Mid 2013 with Yosemite 10.10.5 with Intel HD Graphics 5000 1536 MB
Happy to provide more data and be a guinea pig if it helps
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #38 from Sam sam.h.russell@gmail.com --- Finished build, confirming that this patch worked
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #39 from A.Steinel A.Steinel@gmail.com --- @Sam: The home patch you mentioned is from this very page (from Linus Unnebäck). I use if for over a year without any problems.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #40 from Sam sam.h.russell@gmail.com --- @A.Steinel correct :) I had to back engineer the homebrew script to find this page, despite many forum threads and bug reports mentioning similar symptoms. I've added a link to this bug on the Black and White page so that others can find it a bit more easily in the future
https://appdb.winehq.org/objectManager.php?sClass=version&iId=257
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #41 from David Holm dholmster@gmail.com --- Created attachment 52485 --> https://bugs.winehq.org/attachment.cgi?id=52485 Revert patch updated for wine-1.7.52
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #42 from Sam Russell sam.h.russell@gmail.com --- Patch is still valid with wine-1.7.53
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #43 from Lebostein lebostein@gmx.de --- Hm... The bug is still present. 50% of the games I have tested flickers. Why it is a problem to include that fix in the official release?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #44 from WineBuG winebugs140@gmail.com --- (In reply to Lebostein from comment #43)
Hm... The bug is still present. 50% of the games I have tested flickers. Why it is a problem to include that fix in the official release?
For me these fixes sometimes cause slowdowns and graphical issues. So I don't think this is the right way...
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #45 from Linus Unnebäck linus@folkdatorn.se --- (In reply to WineBuG from comment #44)
For me these fixes sometimes cause slowdowns and graphical issues. So I don't think this is the right way...
Care to give some detail here? I have used this patch with a number of games and never experienced any problems.
We are also shipping this patch by default with brew, which is how I think that most people install wine on OS X and we haven't had any complaints yet.
Are you sure that it's this specific patch that is causing the problem?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #46 from WineBuG winebugs140@gmail.com --- (In reply to Linus Unnebäck from comment #45)
(In reply to WineBuG from comment #44)
Care to give some detail here? I have used this patch with a number of games and never experienced any problems.
We are also shipping this patch by default with brew, which is how I think that most people install wine on OS X and we haven't had any complaints yet.
Are you sure that it's this specific patch that is causing the problem?
Performance issues have already been mention in this very bug report: https://bugs.winehq.org/show_bug.cgi?id=34166#c24 I'm not saying this makes games unplayable or something. And supposedly these problems affect for the most part low-end GPU users.
Brew is some really cool stuff, but I think people rather use Wineskin and WineBottler for Wine on OS X. :)
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #47 from Ken Thomases ken@codeweavers.com --- Comment 24 was about the hack in attachment 47639/attachment 52485. That hack disables OS X's full-screen optimizations, which is how it sidesteps the bug in those optimizations.
The hack in attachment 47352 is a completely different approach and should not affect performance.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #48 from Lebostein lebostein@gmx.de --- 1. Why this bug is unconfirmed?
2. Here are some games with the flickering issue I have tested last week:
http://www.gog.com/game/anno_1503_ad http://www.gog.com/game/the_guild_gold_edition http://www.gog.com/game/age_of_wonders_2_the_wizards_throne http://www.gog.com/game/age_of_wonders_shadow_magic
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #49 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Ken Thomases from comment #47)
The hack in attachment 47352 [details] is a completely different approach and should not affect performance.
I confirm the hack is useful for 3DMark03 and not affects performance. All benchmarks show exactly same results.
(In reply to Lebostein from comment #48)
Why this bug is unconfirmed?
Here are some games with the flickering issue I have tested last week:
http://www.gog.com/game/anno_1503_ad http://www.gog.com/game/the_guild_gold_edition http://www.gog.com/game/age_of_wonders_2_the_wizards_throne http://www.gog.com/game/age_of_wonders_shadow_magic
Yes, I confirm the bug and both solutions works. More affected applications http://www.futuremark.com/benchmarks/legacy
The bug still present in wine-1.8-rc2
https://bugs.winehq.org/show_bug.cgi?id=34166
Kurt kurtjaeke@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kurtjaeke@gmx.de
https://bugs.winehq.org/show_bug.cgi?id=34166
Lucas kameeleonpl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kameeleonpl@gmail.com
--- Comment #50 from Lucas kameeleonpl@gmail.com --- I can agree, the bug still present in 1.8-rc3
Tested game: http://www.gog.com/game/gothic_2_gold_edition
MacBook Air 13"
https://bugs.winehq.org/show_bug.cgi?id=34166
bodja.reg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bodja.reg@gmail.com
--- Comment #51 from bodja.reg@gmail.com --- "Arx Fatalis" is also affected by this bug. (Wine 1.9.2, mac os yosemite)
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #52 from Sergey Isakov isakov-sl@bk.ru --- Game Tumblebugs 2 affected as well. I also see every second game affected.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #53 from Lebostein lebostein@gmx.de --- Gabriel Knight 3 too.
This unconfirmed bug is the main reason, why I use Wineskin occasionally only...
https://bugs.winehq.org/show_bug.cgi?id=34166
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #54 from Jeff Zaroyko jeffz@jeffz.name --- Confirming, wine-1.9.4, intel iris, OS X El Capitan.
Also affects the Direct3D MDK Demo and Jedi Knight Dark Forces II with 3D acceleration enabled.
https://bugs.winehq.org/show_bug.cgi?id=34166
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffz@jeffz.name
--- Comment #55 from Jeff Zaroyko jeffz@jeffz.name --- *** Bug 39760 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34166
dinostroza@fen.uchile.cl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dinostroza@fen.uchile.cl
--- Comment #56 from dinostroza@fen.uchile.cl --- Tried Worms 2 and SimCity 3000 World Edition recently with MacPorts Wine 1.9.4 and they don't have this issue at all. In prior versions of Wine, Worms 2 and SC3K had this flickering problem.
My system is a Hackintosh HP ProBook 440 G1, i5-4200M CPU, Intel HD4600 GPU, running latest El Capitan 10.11.3.
https://bugs.winehq.org/show_bug.cgi?id=34166
sschweizer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sschweizer@gmail.com
--- Comment #57 from sschweizer@gmail.com --- I can confirm the bug in wine 1.9.4 with age of empires 2 the conquerors. Because of this bug I cannot play it on my mac. Unfortunately I cannot build wine on my mac to fix it :(
Can you please officially apply the proposed fix so that I can play again? Thanks!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #58 from sschweizer@gmail.com --- Can we maybe get the "hack" patch without performance issues just fixing this bug applied upstream by creating a "git pull request"? I am unfamiliar with wine development but it seems this was just not fixed/applied because Henri Verbeet did not upload it to the git repository. Is there anyone with an account on github who could upload it on his behalf?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #59 from A.Steinel A.Steinel@gmail.com --- (In reply to sschweizer from comment #58)
Can we maybe get the "hack" patch without performance issues just fixing this bug applied upstream by creating a "git pull request"? I am unfamiliar with wine development but it seems this was just not fixed/applied because Henri Verbeet did not upload it to the git repository. Is there anyone with an account on github who could upload it on his behalf?
Do you use Wineskin for Mac? You create Application Bundles and I built patched versions years ago. I still use this version to play games affected by this bug.
Please see: https://github.com/lnxbil/WineskinEngines
https://bugs.winehq.org/show_bug.cgi?id=34166
acescopezz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acescopezz@gmail.com
--- Comment #60 from acescopezz@gmail.com --- (In reply to A.Steinel from comment #59)
(In reply to sschweizer from comment #58)
Can we maybe get the "hack" patch without performance issues just fixing this bug applied upstream by creating a "git pull request"? I am unfamiliar with wine development but it seems this was just not fixed/applied because Henri Verbeet did not upload it to the git repository. Is there anyone with an account on github who could upload it on his behalf?
Do you use Wineskin for Mac? You create Application Bundles and I built patched versions years ago. I still use this version to play games affected by this bug.
Please see: https://github.com/lnxbil/WineskinEngines
Those engines work perfectly, thank you. But would it be possible to use your patches and apply them to the latest wine version?
Because a game like Empire Earth suffers from mouse issues, which have been fixed in later versions of wine, but not on 1.7.* versions. But these later wine versions suffer from the flickering.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #61 from A.Steinel A.Steinel@gmail.com --- You can try, I haven't. The patches are the ones from this thread and they could work.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #62 from Josh Pettus jshpettus@gmail.com --- I should point out to fix the mouse issue with Empire Earth you can take the dinput.dll (maybe dinput8.dll to be sure) from an actual windows install, copy it to your empire earth folder, and set wine to use native version of dinput
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #63 from acescopezz@gmail.com --- (In reply to Josh Pettus from comment #62)
I should point out to fix the mouse issue with Empire Earth you can take the dinput.dll (maybe dinput8.dll to be sure) from an actual windows install, copy it to your empire earth folder, and set wine to use native version of dinput
Thank you very much for pointing this out, it worked like a charm! The only problem I have now is the mouse drag and the flickering it causes. I'm using a NoFlicker engine but the mouse drag seems to stil exist.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #64 from Lebostein lebostein@gmx.de --- That damned bug drives me CRAZY!!! If there is no expert who can fix this bug!!?
In older versions this bug was fixes already! At the moment I try to play "Syberia" (https://www.gog.com/game/syberia)
With Wineskin 2.6.2 + 1.7.15NoFlicker = IT WORKS! With Wineskin 2.6.2 + 1.9.15 = IT DON'T WORK
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #65 from bodja.reg@gmail.com --- (In reply to Lebostein from comment #64)
That damned bug drives me CRAZY!!! If there is no expert who can fix this bug!!?
In older versions this bug was fixes already! At the moment I try to play "Syberia" (https://www.gog.com/game/syberia)
With Wineskin 2.6.2 + 1.7.15NoFlicker = IT WORKS! With Wineskin 2.6.2 + 1.9.15 = IT DON'T WORK
I think it doesn't work in new versions because 1.7.15NoFlicker is just an unofficial patch of 1.7.15 official release. I hope someday someone will find time to patch latest release. It would be awesome if wine-team cold do releases with support of mac os x opengl api. Or better separate wine's graphics drivers wrapper into 2, and add a possibility to choose which driver to use when you are building wine.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #66 from Sergey Isakov isakov-sl@bk.ru --- There is no problem with this bug. The hack by Henri Verbeet at the top of this page works for me in all cases. Last one with wine-1.9.20 on the gAme TheLongJounreyDemo (bug 11819) as well affected by this bug. My collection of games affected is very long and the hack is always good for me.
https://bugs.winehq.org/show_bug.cgi?id=34166
borjacasbas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |borjacasbas@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #67 from acescopezz@gmail.com --- Henri's patch doesn't apply cleanly to wine-1.9.21 anymore. This is a big issue, it would be really appreciated if Henri could maybe take a look at it. This is the output of the patch command: Hunk #1 succeeded at 1417 (offset 311 lines). Hunk #2 succeeded at 1424 with fuzz 1 (offset 309 lines). Hunk #3 FAILED at 1438. Hunk #4 succeeded at 1445 with fuzz 2 (offset 300 lines). Hunk #5 FAILED at 1468. Hunk #6 succeeded at 1501 with fuzz 2 (offset 300 lines). Hunk #7 succeeded at 1770 with fuzz 1 (offset 376 lines). 2 out of 7 hunks FAILED -- saving rejects to file dlls/wined3d/context.c.rej
https://bugs.winehq.org/show_bug.cgi?id=34166
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47352|0 |1 is obsolete| |
--- Comment #68 from Ken Thomases ken@codeweavers.com --- Created attachment 55968 --> https://bugs.winehq.org/attachment.cgi?id=55968 Updated hack
Here is a version of Henri's hack that's been updated to apply to current Wine.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #69 from acescopezz@gmail.com --- (In reply to Ken Thomases from comment #68)
Created attachment 55968 [details] Updated hack
Here is a version of Henri's hack that's been updated to apply to current Wine.
Thank you very much, greatly appreciated!
https://bugs.winehq.org/show_bug.cgi?id=34166
Ricardo van den Broek ricardovdbroek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ricardovdbroek@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34166
Mike McQuaid mike@mikemcquaid.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@mikemcquaid.com
--- Comment #70 from Mike McQuaid mike@mikemcquaid.com --- Hi, Mike McQuaid, lead Homebrew maintainer here. Is there any chance of this patch getting merged for a future Wine stable release? Homebrew doesn't want to carry patches like this indefinitely as we consider upstream a better judge than us on the suitability of patches. If there's no chance in this getting merged we'll consider removing it and direct people to this bug report instead. Thanks for all your work on Wine!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #71 from Henri Verbeet hverbeet@gmail.com --- (In reply to Mike McQuaid from comment #70)
Hi, Mike McQuaid, lead Homebrew maintainer here. Is there any chance of this patch getting merged for a future Wine stable release? Homebrew doesn't want to carry patches like this indefinitely as we consider upstream a better judge than us on the suitability of patches. If there's no chance in this getting merged we'll consider removing it and direct people to this bug report instead. Thanks for all your work on Wine!
Probably not. Wined3d policy is to fix things in the correct place, and this is a bug in OS X. You may still want to consider carrying this particular patch along though, since it currently seems fairly unlikely that Apple is ever going to fix this bug, and it does affect a large number of applications.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #72 from bodja.reg@gmail.com --- (In reply to Henri Verbeet from comment #71)
(In reply to Mike McQuaid from comment #70)
Hi, Mike McQuaid, lead Homebrew maintainer here. Is there any chance of this patch getting merged for a future Wine stable release? Homebrew doesn't want to carry patches like this indefinitely as we consider upstream a better judge than us on the suitability of patches. If there's no chance in this getting merged we'll consider removing it and direct people to this bug report instead. Thanks for all your work on Wine!
Probably not. Wined3d policy is to fix things in the correct place, and this is a bug in OS X. You may still want to consider carrying this particular patch along though, since it currently seems fairly unlikely that Apple is ever going to fix this bug, and it does affect a large number of applications.
As i understand it's not a bug, it's an optimization feature from osx. Isn't it?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #73 from Mike McQuaid mike@mikemcquaid.com --- Given you officially support macOS as a platform, Apple haven't changed this, you recommend Homebrew as an installation method and there's a non-trivial number of Homebrew Wine users: is there any way you could consider merging this patch? As mentioned before I don't feel Homebrew maintainers are suitable for deciding whether a Wine patch is appropriate or not and getting things upstream benefits other macOS package managers and those who build from source on that platform. Thanks again!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #74 from Sam Russell sam.h.russell@gmail.com --- (In reply to Mike McQuaid from comment #73)
Given you officially support macOS as a platform, Apple haven't changed this, you recommend Homebrew as an installation method and there's a non-trivial number of Homebrew Wine users: is there any way you could consider merging this patch? As mentioned before I don't feel Homebrew maintainers are suitable for deciding whether a Wine patch is appropriate or not and getting things upstream benefits other macOS package managers and those who build from source on that platform. Thanks again!
I agree with Mike here - it's great that Wine has worked so well across multiple platforms for so long, but one can expect that they're only going to continue to diverge as time goes on. What plans are there for managing this long term? Should we be building platform-specific makefiles to handle this?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #75 from Sam Russell sam.h.russell@gmail.com --- Have just built wine from head and confirmed that the flickering still happens in OSX Yosemite. It happens that taking a screen shot (command + shift + 3) sometimes stops the flickering, so this might be a useful workaround
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #76 from Sam Russell sam.h.russell@gmail.com --- Created attachment 57066 --> https://bugs.winehq.org/attachment.cgi?id=57066 patch updated for wine-2.0
update the patch, tested against HEAD as of this post (should track against wine-2.0 too)
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #77 from Henri Verbeet hverbeet@gmail.com --- (In reply to Mike McQuaid from comment #73)
Given you officially support macOS as a platform, Apple haven't changed this, you recommend Homebrew as an installation method and there's a non-trivial number of Homebrew Wine users: is there any way you could consider merging this patch? As mentioned before I don't feel Homebrew maintainers are suitable for deciding whether a Wine patch is appropriate or not and getting things upstream benefits other macOS package managers and those who build from source on that platform. Thanks again!
I'm afraid I'll have to disappoint, it's really up to Apple to fix this. There may be architectural changes that may mitigate the issue in the future, but I can't promise that.
The thing is that the Apple OpenGL implementation has many more bugs and quirks than just this one, and while the individual workarounds for those may seem innocent enough on their own, those quickly add up to something unmaintainable. The other consideration is that Wine is primarily a Free Software project, and has comparatively few users and developers on MacOS. That means that even if we did include those kinds of workarounds, it would be relatively easy to inadvertently break them again.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #78 from Dr 4asm ignas2526@gmail.com --- (In reply to Henri Verbeet from comment #77)
(In reply to Mike McQuaid from comment #73)
Given you officially support macOS as a platform, Apple haven't changed this, you recommend Homebrew as an installation method and there's a non-trivial number of Homebrew Wine users: is there any way you could consider merging this patch? As mentioned before I don't feel Homebrew maintainers are suitable for deciding whether a Wine patch is appropriate or not and getting things upstream benefits other macOS package managers and those who build from source on that platform. Thanks again!
I'm afraid I'll have to disappoint, it's really up to Apple to fix this. There may be architectural changes that may mitigate the issue in the future, but I can't promise that.
The thing is that the Apple OpenGL implementation has many more bugs and quirks than just this one, and while the individual workarounds for those may seem innocent enough on their own, those quickly add up to something unmaintainable. The other consideration is that Wine is primarily a Free Software project, and has comparatively few users and developers on MacOS. That means that even if we did include those kinds of workarounds, it would be relatively easy to inadvertently break them again.
While it might be Apple's fault, in the end, some applications are pretty much unusable in the wine on the Mac because of this. To be on a same page, I invite you to try to run one of the affected apps for couple minutes with it flickering at 20+ fps. I hope you don't have photosensitive epilepsy.
I've been following this bug for a long time, and as far as I can tell, it is not being fixed due to some ego issues. At least some of the developers here seem to be obsessed with creating this clean, pure implementation that has no "workarounds"... What you're forgetting, is that we're living in an imperfect world, where every single OS is flawed. No matter how hard you try, at the end of the day, you will have to write code to deal with OS's quirks. Unless, you don't care about your software being usable. At this point, you should ask yourselves: are we creating something for real users out there or are we creating something to show off? It seems like the goal here is the second.
As for lack of MacOS users, well, if the software is unusable, why do you expect it to have users?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #79 from Henri Verbeet hverbeet@gmail.com --- Why did I even bother?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #80 from Lebostein lebostein@gmx.de --- This "bug" is existent since over 4 years. And we all know: Apple will never fix this bug. If they have not done it for the last four years, they will never do it. And we all know: In the IT we have live with workarounds in some cases. And in that case WE NEED a workaround, because a fix is not in sight.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #81 from Mike McQuaid mike@mikemcquaid.com --- I agree with the previous comments. As a Homebrew maintainer it would be great if this could be merged in some form (or fixed in another) so we don't need to rebase this patch indefinitely when the underlying code changes.
That means that even if we did include those kinds of workarounds, it would be relatively easy to inadvertently break them again.
That's fine and understood. The main thing is at least then the patch won't need continually applied and rebased by downstream package manager(s).
https://bugs.winehq.org/show_bug.cgi?id=34166
alexchandel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexchandel@gmail.com
--- Comment #82 from alexchandel@gmail.com --- (In reply to Henri Verbeet from comment #77)
(In reply to Mike McQuaid from comment #73)
Given you officially support macOS as a platform, Apple haven't changed this, you recommend Homebrew as an installation method and there's a non-trivial number of Homebrew Wine users: is there any way you could consider merging this patch? As mentioned before I don't feel Homebrew maintainers are suitable for deciding whether a Wine patch is appropriate or not and getting things upstream benefits other macOS package managers and those who build from source on that platform. Thanks again!
I'm afraid I'll have to disappoint, it's really up to Apple to fix this. There may be architectural changes that may mitigate the issue in the future, but I can't promise that.
The thing is that the Apple OpenGL implementation has many more bugs and quirks than just this one, and while the individual workarounds for those may seem innocent enough on their own, those quickly add up to something unmaintainable. The other consideration is that Wine is primarily a Free Software project, and has comparatively few users and developers on MacOS. That means that even if we did include those kinds of workarounds, it would be relatively easy to inadvertently break them again.
I hate to break it to you, but wine has hundreds of thousands of macOS users. It's used in many universities and corporations with Apple hardware (more than you'd think, I know from experience), and generally by Apple users running Windows-only programs. The patch is applied universally, and this is a bug worth fixing.
https://bugs.winehq.org/show_bug.cgi?id=34166
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #83 from Henri Verbeet hverbeet@gmail.com --- Resolving.
https://bugs.winehq.org/show_bug.cgi?id=34166
Misty De Meo mistydemeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mistydemeo@gmail.com
--- Comment #84 from Misty De Meo mistydemeo@gmail.com --- I've filed a radar with Apple for the bug in their implementation: rdar://30449915
If someone familiar with Wine could assist in making a minimal testcase that repros this bug, I think that would help expedite getting things fixed with Apple.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #85 from Sergey Isakov isakov-sl@bk.ru --- Even if Apple will correct this bug in one of the nest system most users will encounter problems with wine on existing macOS.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #86 from acescopezz@gmail.com --- (In reply to Ken Thomases from comment #68)
Created attachment 55968 [details] Updated hack
Here is a version of Henri's hack that's been updated to apply to current Wine.
Hey Ken, could you maybe update your hack again, because it doesn't apply to current git anymore. (and I think the other hack only works when macdrv is enabled. If I'm wrong, then I'm sorry for bothering you)
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #87 from Gijs Vermeulen acescopezz@gmail.com --- Created attachment 57352 --> https://bugs.winehq.org/attachment.cgi?id=57352 updated hack
I modified Henri's (and Ken's) hack to apply to current git.
https://bugs.winehq.org/show_bug.cgi?id=34166
Gijs Vermeulen acescopezz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57352|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #88 from Gijs Vermeulen acescopezz@gmail.com --- Created attachment 57353 --> https://bugs.winehq.org/attachment.cgi?id=57353 updated hack
(In reply to Gijs Vermeulen from comment #87)
Created attachment 57352 [details] updated hack
I modified Henri's (and Ken's) hack to apply to current git.
Oops, attached the wrong version.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #89 from Misty De Meo mistydemeo@gmail.com --- Reply from Apple:
We have determined that this is an issue for you to resolve.
I think you just need to set the right pixel format bit to say you expect the back buffer to remain consistent after rendering and not perform a page flip. In that case you can still go exclusive (I think) but we'll do back to front blits if the do a CGLFlushDrawable. Nothing short of a CGLFlush (or equivalent) should be forcing the actual buffer flip to happen, though.
In any case, you should try using the kCGLPFABackingStore pixel format attribute to prevent the buffer swaps from happening. If that doesn't resolve it we'd have to dig deeper.
Please let us know whether the issue is resolved for you by updating your bug report.
https://bugs.winehq.org/show_bug.cgi?id=34166
joaaa118@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joaaa118@gmail.com
--- Comment #90 from joaaa118@gmail.com --- Hello, obviously I'm late to the party but I'm trying to play Black&White using Wine at the moment. Everything is working fine except for this flickering issue. Some people are talking about a fix for the bug, unofficial or not I dont care. But can someone please explain to me how exactly I'm supposed to download these fixes? I'm no master programmer, nor do I know how to really use the terminal all that much and when I follow the attachment pages I just see text. Can anyone please help me? This page does seem sort of active still in 2017 this month so I am hoping I get a reply! Thank you so much!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #91 from A.Steinel A.Steinel@gmail.com --- (In reply to joaaa118 from comment #90)
Hello, obviously I'm late to the party but I'm trying to play Black&White using Wine at the moment. Everything is working fine except for this flickering issue. Some people are talking about a fix for the bug, unofficial or not I dont care. But can someone please explain to me how exactly I'm supposed to download these fixes? I'm no master programmer, nor do I know how to really use the terminal all that much and when I follow the attachment pages I just see text. Can anyone please help me? This page does seem sort of active still in 2017 this month so I am hoping I get a reply! Thank you so much!
How do you install wine at the moment?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #92 from joaaa118@gmail.com --- (In reply to A.Steinel from comment #91)
(In reply to joaaa118 from comment #90)
Hello, obviously I'm late to the party but I'm trying to play Black&White using Wine at the moment. Everything is working fine except for this flickering issue. Some people are talking about a fix for the bug, unofficial or not I dont care. But can someone please explain to me how exactly I'm supposed to download these fixes? I'm no master programmer, nor do I know how to really use the terminal all that much and when I follow the attachment pages I just see text. Can anyone please help me? This page does seem sort of active still in 2017 this month so I am hoping I get a reply! Thank you so much!
How do you install wine at the moment?
Hello! Thank you for your quick reply. I'm not sure if this is the information you want but here is what I've done so far. I downloaded Wineskin Winery, set up wine 2.3 as my engine, using Wine-2.6.2. Afterwards I made a wrapper and proceeded to install black and white. The only modification I did to my game was replace one of my filed in order to allow me to play CD free.
If there is more info about this I can provide please let me know!
Furthermore, everytime I seem to launch my game via test run on my wrapper, the rapper seems to crash almost instantly before my game starts playing. The game itself runs almost perfectly with the only two issues I've found being that music will not play (an issue I think I can resolve). But the key issue is simply that the game will not stop flickering at all and the flickering gets worse with increased brightness. Also, black and white has no windowed option - I tried to window it via my wrapper but since it crashes I dont know if this works or if the game just cant be shrunk down. Flickering is the only true issue but it seriously impairs my ability to play the game at all.
Anyways like I said If I failed to answer what you were looking for please let me know!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #93 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to joaaa118 from comment #92)
(In reply to A.Steinel from comment #91)
Please take this discussion to the WineHQ forum: http://forum.winehq.org. Bugzilla is not the place to request general help, it's for reporting bugs.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #94 from bodja.reg@gmail.com --- (In reply to joaaa118 from comment #92)
(In reply to A.Steinel from comment #91)
(In reply to joaaa118 from comment #90)
Hello, obviously I'm late to the party but I'm trying to play Black&White using Wine at the moment. Everything is working fine except for this flickering issue. Some people are talking about a fix for the bug, unofficial or not I dont care. But can someone please explain to me how exactly I'm supposed to download these fixes? I'm no master programmer, nor do I know how to really use the terminal all that much and when I follow the attachment pages I just see text. Can anyone please help me? This page does seem sort of active still in 2017 this month so I am hoping I get a reply! Thank you so much!
How do you install wine at the moment?
Hello! Thank you for your quick reply. I'm not sure if this is the information you want but here is what I've done so far. I downloaded Wineskin Winery, set up wine 2.3 as my engine, using Wine-2.6.2. Afterwards I made a wrapper and proceeded to install black and white. The only modification I did to my game was replace one of my filed in order to allow me to play CD free.
If there is more info about this I can provide please let me know!
Furthermore, everytime I seem to launch my game via test run on my wrapper, the rapper seems to crash almost instantly before my game starts playing. The game itself runs almost perfectly with the only two issues I've found being that music will not play (an issue I think I can resolve). But the key issue is simply that the game will not stop flickering at all and the flickering gets worse with increased brightness. Also, black and white has no windowed option - I tried to window it via my wrapper but since it crashes I dont know if this works or if the game just cant be shrunk down. Flickering is the only true issue but it seriously impairs my ability to play the game at all.
Anyways like I said If I failed to answer what you were looking for please let me know!
Here is wineskin engine with no-flickering patch. Download it and copy into the /Users/<your username>/Library/Application Support/Wineskin/Engines
https://github.com/bodja/WineskinEngines/raw/master/WS10Wine2.1NoFlicker.tar...
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #95 from joaaa118@gmail.com --- (In reply to bodja.reg from comment #94)
(In reply to joaaa118 from comment #92)
(In reply to A.Steinel from comment #91)
(In reply to joaaa118 from comment #90)
Hello, obviously I'm late to the party but I'm trying to play Black&White using Wine at the moment. Everything is working fine except for this flickering issue. Some people are talking about a fix for the bug, unofficial or not I dont care. But can someone please explain to me how exactly I'm supposed to download these fixes? I'm no master programmer, nor do I know how to really use the terminal all that much and when I follow the attachment pages I just see text. Can anyone please help me? This page does seem sort of active still in 2017 this month so I am hoping I get a reply! Thank you so much!
How do you install wine at the moment?
Hello! Thank you for your quick reply. I'm not sure if this is the information you want but here is what I've done so far. I downloaded Wineskin Winery, set up wine 2.3 as my engine, using Wine-2.6.2. Afterwards I made a wrapper and proceeded to install black and white. The only modification I did to my game was replace one of my filed in order to allow me to play CD free.
If there is more info about this I can provide please let me know!
Furthermore, everytime I seem to launch my game via test run on my wrapper, the rapper seems to crash almost instantly before my game starts playing. The game itself runs almost perfectly with the only two issues I've found being that music will not play (an issue I think I can resolve). But the key issue is simply that the game will not stop flickering at all and the flickering gets worse with increased brightness. Also, black and white has no windowed option - I tried to window it via my wrapper but since it crashes I dont know if this works or if the game just cant be shrunk down. Flickering is the only true issue but it seriously impairs my ability to play the game at all.
Anyways like I said If I failed to answer what you were looking for please let me know!
Here is wineskin engine with no-flickering patch. Download it and copy into the /Users/<your username>/Library/Application Support/Wineskin/Engines
https://github.com/bodja/WineskinEngines/raw/master/WS10Wine2.1NoFlicker.tar. 7z
Hi, thank you so much! This simplifies things quite a bit! Just one issue, after searching throughout my mac I can't seem to be able to find anything under application support. Is there another area I'm supposed to put the bug fix into? For example do I put it into the /c drive of the wrapper or is this something that goes into the wineskin winery. Again, forgive my utter lack of knowledge for all things technical! However, you guys have been super helpful so far! Also I dont think its a bad idea to keep this stuff on this page. After all, it looks like people have been cursed with this bug since 2013!
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #96 from joaaa118@gmail.com --- Nevermind, found the issue! Works like a charm! Thank you guys! You rock! :)
https://bugs.winehq.org/show_bug.cgi?id=34166
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57353|0 |1 is obsolete| |
--- Comment #97 from Gijs Vermeulen gijsvrm@gmail.com --- Created attachment 58950 --> https://bugs.winehq.org/attachment.cgi?id=58950 updated hack
Here's another updated version of Ken's and Henri's hack.
https://bugs.winehq.org/show_bug.cgi?id=34166
Evgenii Burmentev [:virus_found] vir.found@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vir.found@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #98 from Lebostein lebostein@gmx.de --- 2018... nothing happened. This is the one and only bug why I don't use Wine on Mac OS in most cases... It is to complex to include that hack with a checkbox in Winericks to activate that hack?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #99 from Linus Unnebäck linus@folkdatorn.se --- It seems to me that in the last response to Apple, they suggested setting the kCGLPFABackingStore pixel format attribute. They also say that they would have to dig deeper if we are already doing that.
In any case, you should try using the kCGLPFABackingStore pixel format attribute to prevent the buffer swaps from happening. If that doesn't resolve it we'd have to dig deeper.
I tried looking around in the Wine source for that attribute, and it seems that it's at least being set in some cases. There are three occurrences of kCGLPFABackingStore in the winemac.drv/opengl.c code.
Maybe someone more familiar with the code could work out if we are actually setting this attribute or not when the flickering occurs. If we aren't, maybe we just need to do that, and if we are, we should update the Apple issue with that so that they can continue to investigate.
This bug is still something that affects a ton of games, let's not stop trying to fix it just because this issue has been marked as "NOTOURBUG"!
https://bugs.winehq.org/show_bug.cgi?id=34166
Mike McQuaid mike@mikemcquaid.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mike@mikemcquaid.com |
https://bugs.winehq.org/show_bug.cgi?id=34166
fxcoudert@gcc.gnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert@gcc.gnu.org
--- Comment #100 from fxcoudert@gcc.gnu.org --- Following on Apple's feedback quoted above, which was:
It seems to me that in the last response to Apple, they suggested setting the kCGLPFABackingStore pixel format attribute. They also say that they would have to dig deeper if we are already doing that.
I wanted to see if that could help. Therefore I wrote a crude patch to winemac.drv/opengl.c that adds kCGLPFABackingStore to every single pixel format, i.e., to every call to CGLChoosePixelFormat(). That patch can be found at: https://gist.github.com/fxcoudert/539dc389d5f651bf713f684d43bb254b
We received user feedback (https://github.com/Homebrew/homebrew-core/pull/26114#issuecomment-379534814) that this patch, without the usual "hack", does seem to fix the issue. Could more users here test, with and without, and confirm?
If so, it would indicate that the issue is one or several missing kCGLPFABackingStore attributes in winemac.drv/opengl.c. I am not expert enough with the code to tell which one, but surely the Wine developers would know which are the affected buffers.
https://bugs.winehq.org/show_bug.cgi?id=34166
bigboss78@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bigboss78@gmail.com
--- Comment #101 from bigboss78@gmail.com --- (In reply to bodja.reg from comment #94)
Here is wineskin engine with no-flickering patch. Download it and copy into the /Users/<your username>/Library/Application Support/Wineskin/Engines
https://github.com/bodja/WineskinEngines/raw/master/WS10Wine2.1NoFlicker.tar. 7z
Hi, just registered to say THANK YOU, you just solved the problem for me, and I don't think your comment has enough visibility so I hope more people can see this, because you just provided the real solution to the problem.
Cheers!
https://bugs.winehq.org/show_bug.cgi?id=34166
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #102 from Fabian Maurer dark.shadow4@web.de --- Did someone already bother to write a test program? If you want apple to fix the issue, that's probably a good idea.
We received user feedback (https://github.com/Homebrew/homebrew-core/pull/26114#issuecomment- 379534814) that this patch, without the usual "hack", does seem to fix the issue. Could more users here test, with and without, and confirm?
Noone yet?
Just curious, why does wine request a double buffer in the first place when only one buffer is used?
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #103 from Ken Thomases ken@codeweavers.com --- Created attachment 61513 --> https://bugs.winehq.org/attachment.cgi?id=61513 Patch to add a registry key to force preservation of the OpenGL backing store
We don't want to force the preservation of the backing store all the time, because it hurts performance for apps which use a double buffer.
The attached patch adds support for a registry key to control whether it's forced or not (default to not forced). To test it, apply the patch, build Wine, and set the following registry key in your prefix:
[HKCU\Software\Wine\Mac Driver] "ForceOpenGLBackingStore"="y"
If this works for folks, I'm willing to submit it for inclusion in Wine.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #104 from Linus Unnebäck linus@folkdatorn.se --- I haven't been able to reproduce this bug in any version of Wine on macOS 10.13.4 (17E202). Seems to me that maybe Apple actually fixed the issue.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #105 from bigboss78@gmail.com --- (In reply to Linus Unnebäck from comment #104)
I haven't been able to reproduce this bug in any version of Wine on macOS 10.13.4 (17E202). Seems to me that maybe Apple actually fixed the issue.
It appears in an old MacBook Pro (early 2011, Intel HD 3000), but it doesn't in an early 2015 Air (Intel HD 6000); both with macOS 10.13.5. I assume the former is just forgotten by Apple support.
Again, the engine posted by bodja.reg works great in both machines.
https://bugs.winehq.org/show_bug.cgi?id=34166
--- Comment #106 from Jeff Zaroyko jeffz@jeffz.name --- Retina 15-inch Late 2013, Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz, Intel® Iris™ Pro Graphics 5200.
I used to be able to reproduce this with the jedi knight dark forces II demo:
https://archive.org/details/StarWarsJediKnightDarkForcesII_1020
I can no longer reproduce the issue with macOS High Sierra 10.13.4. $ uname -a Darwin Jeffs-MacBook-Pro.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64)
https://bugs.winehq.org/show_bug.cgi?id=34166
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #107 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=34166
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #108 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
-
wine-bugs＠winehq.org