https://bugs.winehq.org/show_bug.cgi?id=35418 --- Comment #25 from Sebastian <gustep12(a)yahoo.com> --- Great, looking forwards to it. How can I test the fix? Also, I agree that rendering performance (in GDI operations per second) is important, but not the only consideration. The on-screen appearance should also be considered: 1.) Is the final screen correct? DIB may have some advantages here. 2.) Are animations fluid and responsive? Direct rendering may be better. My general impression is: With ClientSideGraphics=N, WINE emulates WinXP behavior faithfully (direct rendering) With ClientSideGraphics=Y, WINE emulates Win7 behavior (DIB buffering), but with a difference: Namely, in Tom's 2DBench.exe, Windows 7 appears to present the final image after the buffer flush for a *significantly* longer time than WINE with ClientSideGraphics=Y. The overall result appears to be: WinXP direct rendering: Fluid animation with many frames (very fast) WinXP DIB buffering: Only final frame appears (for maybe 1/30th of a second) WINE ClientSideGraphics=N direct rendering: Like WinXP direct rendering WINE ClientSideGraphics=N DIB buffering: Like WinXP DIB buffering Win7 direct rendering: Slow animation with many frames (long final frame) Win7 DIB buffering: Only final frame appears (significantly longer than XP!) WINE ClientSideGraphics=Y direct rendering: Most times nothing appears (???) WINE ClientSideGraphics=Y DIB buffering: Most times nothing appears (???) Basically, Windows 7 appears to add a small pause after the rendering is complete to ensure that it is actually displayed. In WINE with ClientSideGraphics=Y, is it possible that the buffer is either not reliably flushed, or flushed but immediately replaced with something else before it ever had a chance time to appear on the display? -- 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.