http://bugs.winehq.org/show_bug.cgi?id=35718
--- Comment #23 from Ken Thomases ken@codeweavers.com --- (In reply to Jan from comment #19)
Created attachment 47874 [details] +tid,+d3d,+wgl log with Anno 1602
A +tid,+d3d,+wgl log of Anno 1602 with trace patch applied. Uncompressed to only 3.3MiB.
(In reply to Frédéric Delanoy from comment #21)
Created attachment 47879 [details] +tid,+d3d,+wgl log on Path of Exile wine 1.7.14 + patch from attachment 47866 [details]
Flicker still happens, but X display isn't messed up with this patch (only had to reset with 'xrandr -s 0' afterwards)
Both of these logs show the same underlying cause. The game does not set the pixel format for its window. In theory, that means that wined3d should not need to restore the pixel format because the game doesn't care. However, there's a limitation that leads wined3d to be confused and think it does have to restore it.
Basically, wined3d uses one context for a short while. That context finds that the window's pixel format is initially 0. When it's done with the window, it would like to restore it to 0, but it's not actually able to. So, it just leaves the window with whatever pixel format it has.
Then, wined3d starts using a second context and it (with some graphics drivers) wants to use a different pixel format. This second context finds that the window already has a pixel format. It assumes it was set by the game, so it figures it has to restore it before it returns control back to the game. So, it keeps changing the pixel format every time the game calls into DirectDraw/Direct3D and then changing it back when it returns.
This thrashing of the pixel format causes problems with the X11 driver. The X11 driver has to tear down and recreate the drawable each time it changes. This is what causes the flickering and unresponsiveness.