https://bugs.winehq.org/show_bug.cgi?id=42324
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57133|0 |1 is obsolete| |
--- Comment #14 from Ken Thomases ken@codeweavers.com --- Created attachment 57235 --> https://bugs.winehq.org/attachment.cgi?id=57235 Patch to restrict pixel formats for multi-renderer systems
(In reply to Rastafabi from comment #13)
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.
I'm not sure why the old patch wouldn't apply. I've replaced it with one that's been rebased on the tip (wine-2.1-126-g06c5a9a). If it doesn't apply, please explain what you're doing and how it's failing.
In any case, a broken or misapplied patch to the opengl.c file within the Mac driver code should not break general window drawing. Programs which don't use OpenGL would not be affected by that code at all.
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?
It doesn't make things immediately clearer to me, no. Are you using the same winver regardless of the build? (For example, you might be using Win7 for 64-bit but WinXP for 32-bit.)
When you say the "issue persists with 64bit builds of the very same engines", I'm not sure which thing you kept the same and which you changed? Do you mean the issue (only) affects 32-bit Windows apps running in a WoW64 Wine build?
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.
The problem is that it's not clear how to do things differently so that it won't be affected by the issue. The OpenGL context may be created before the window is shown on the screen or positioned on the screen where you will use it. It's actually possible to create it using an HDC from one window and then use it with a different window. It's not clear to me if, on Windows, screens connected to different GPUs count as a different "devices" in the sense of the HDC. In any case, Wine doesn't currently have the infrastructure to treat things that way.
The Mac driver can't destroy and recreate the OpenGL context when it detects which screen the window has been shown on or moved to. The app may have done one-time configuration of the context after it was first created and the Mac driver can't make it repeat the configuration for the new context.