[Bug 51848] Performance Regression in Secondhand Lands

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51848

--- Comment #7 from Henri Verbeet <hverbeet at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.