https://bugs.winehq.org/show_bug.cgi?id=42324
--- Comment #13 from Rastafabi f.platte@platte-web.de --- First off thank you for diagnosing the issue though not having access to a system for inspection. However the fix does not seem to work. I couldn't apply it without removing the first 2 lines, which might have broken it's purpose (I'm not that into it). While I could apply the patch afterwards it ended up in a useless MacDriver which couldn't even draw a window whatsoever.
Apart from this I observed another important factor. It may not necessarily be valid in general, but the few test cases I tried so far all have this in common. While the issue I described earlier basically still is true it only applies in special cases: The issue does not exist, when running those 32bit DirectX 9 executables (Valley/Heaven benchmark) in a pure 32bit wine build, while they issue persists with 64bit builds of the very same engines (tried several back to 1.9.9). So far I haven't tested wether 64bit Direct x9 programs suffer from the same issues (while being run in WOW64 and pure 64bit wine prefixes). Can anyone recommend a DX9-64bit test executable? (available in 32 & 64bit). Speaking of different build though I can tell so far that 64bit OpenGL exes (Cinebench/GPUTest 0.7.0) aren't affected while I cannot tell about 32bit ones (any recommendations?)
Does this clear anything or is it getting even more twisted?
--- I understood how the GL context switching works and why. However I still think, that while it is API conform it does not apply do real-world conditions as even nativ Mac application do not do so (seemingly for a good reason - black screen and significant performance drops until restarted, even when moved to the screen with the MUCH faster PU). That's why I think it should be changed or at better switchable using some registry keys.