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.