Posted December 29, 2015
I know there is a patch for Wine, but as I said above, it tanks performance. There is no fix for the issue unless someone can get Apple fix their OpenGL implementation. The only ones that could convince Apple to look into it are either Crossover or GOG (nudge Judas) since they have a financial interest in Wine working properly. The issue is explained here:
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.
https://bugs.winehq.org/show_bug.cgi?id=34166#c4Short 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.