https://bugs.winehq.org/show_bug.cgi?id=51848
--- Comment #7 from Henri Verbeet hverbeet@gmail.com --- Created attachment 71508 --> https://bugs.winehq.org/attachment.cgi?id=71508 patch
(In reply to Chiitoo from comment #4)
However, it's possible to run the client directly by giving it anything as an argument like so:
'Client.exe 123'
Thanks, that helps a lot, and I'm able to reproduce the issue now. The attached patch helps here, although I don't believe it's entirely correct. (In particular, it will incorrectly clear a pixel format previously set by the application in some cases.)
(In reply to Conor McCarthy from comment #6)
I think this is a driver problem. The chosen GL pixel format with WGL_SWAP_COPY_ARB is identical to the one chosen without this patch except for the different swap attribute. I found nothing wrong with how the pixel format is used. There were no GL errors and no assertion failures in a Mesa debug build. No effect occurs in swapchain_gl_present() because swapchain_present_is_partial_copy() is false anyway. The problem persists if the changes to swapchain_gl_present() are reverted.
The problem seems to be a bit more subtle; always using a WGL_SWAP_COPY_ARB format also works fine. The issue in this particular application is that the application first creates swapchains with a "copy" swap effect, and then later creates a swapchain with a "non-copy" swap effect on the same window. That causes us to end up switching between the two different pixel formats, even though the original context that needed the WGL_SWAP_COPY_ARB pixel format has long since been destroyed. On the winex11 side, changing the pixel format causes the GL drawable to be recreated, and that's the cause of the flickering, and likely the slowdown as well.