Additional info: GeForce 410M, nVidia driver 331.49 (same issue with previous driver), kernel 3.11 (ubuntu 13.10 64bit)

Please try attachment 47706 [details] from bug 35705 to see if it helps.

(In reply to Ken Thomases from comment #2)
> Please try attachment 47706 [details] from bug 35705 to see if it helps.

It doesn't help much: X doesn't crash now, but screen flickering is much increased, and startup is still stuck (at the flickering "Loading..." (full)screen).

[Kubuntu 13.10 amd64 on a laptop with hybrid Intel SNA and discrete Nvidia NVS 4200m graphics]

Here the game starts propertly if on Intel graphics, but when running it on the Nvidia card via primusrun it crashes when it's about to display the main menu.

Created attachment 47758 [details]
Patch to use existing client window if visual is the same

Does this help?  It applies on top of attachment 47706 [details] from bug 35705.

(In reply to Ken Thomases from comment #5)
> Created attachment 47758 [details]
> Patch to use existing client window if visual is the same
> 
> Does this help?  It applies on top of attachment 47706 [details] from bug
> 35705.

No. Same result as in comment 3.

In today's git and nvidia hardware, I am able to load PoE up to the main screen, but the game is unplayable because it flickers very slowly. Kind of like a slow metronome.

I have a similar issue with commit 4c4552c when trying to start Anno 1602. The game changes resolution but the screen stays black when using todays git.

*** Bug 35767 has been marked as a duplicate of this bug. ***

*** Bug 35749 has been marked as a duplicate of this bug. ***

*** Bug 35791 has been marked as a duplicate of this bug. ***

Created attachment 47808 [details]
Patch to avoid destroying and recreating drawable as pixel format is changed

Please try this patch.  It should apply to current git and doesn't require any other patches.

The new patch does fix the blank screen when starting Anno 1602 for me. In-game seems to be working as it should, but the menus are behaving oddly. They're rendered correctly, but there's some kind of input lag happening when trying to interact with any of it. Selecting an option most of the time does nothing. Sometimes the proper action happens after a delay of several seconds, sometimes clicking and holding the mouse button longer triggers the action.

/* continuing over from Bug 35749 */

Tested with attachment 47808 [details] on latest git. With it, the stuttering now seems more "coarse grained" and I can now easily trigger it with only a single alt-tabbing, while previously, it most often took alt-tabbing 3-5 times to trigger and rarely any less.

With patch from attachment 47808 [details], no more flickering/crash in Path of Exile.

However, only game mouse pointer is shown above black screen (and sound played), but no other UI displayed/usable.
Display is messed up (e.g. can't switch to other workspaces in XFCE).

Attachment 47808 [details] does not apply on top of the latest wine (1.7.15).

patching file dlls/winex11.drv/opengl.c
Hunk #3 FAILED at 1265.
Hunk #4 FAILED at 1338.
Hunk #5 FAILED at 1358.
Hunk #6 succeeded at 1393 (offset -1 lines).
Hunk #7 succeeded at 1447 (offset -1 lines).
Hunk #8 FAILED at 1471.
Hunk #9 succeeded at 1788 (offset -1 lines).
Hunk #10 succeeded at 1799 (offset -1 lines).
Hunk #11 succeeded at 1841 (offset -1 lines).
Hunk #12 succeeded at 1854 (offset -1 lines).
Hunk #13 succeeded at 1933 (offset -1 lines).
Hunk #14 succeeded at 1959 (offset -1 lines).
Hunk #15 succeeded at 2968 (offset -1 lines).
Hunk #16 succeeded at 2982 (offset -1 lines).
Hunk #17 succeeded at 3222 (offset -1 lines).
4 out of 17 hunks FAILED -- saving rejects to file dlls/winex11.drv/opengl.c.rej
patching file dlls/winex11.drv/window.c
patching file dlls/winex11.drv/x11drv.h

Created attachment 47866 [details]
Patch to improve diagnostics around pixel formats

OK, let's try a different approach.  This patch is not intended to fix the issue; it just gives me additional diagnostics.

Please apply it (to current git, no other patches) and collect a +tid,+d3d,+wgl log.  Run the game just long enough to be sure the problem has manifested, to keep the log short.  Then, please attach it here.

Thanks.

Created attachment 47872 [details]
+tid,+d3d,+wgl log on CS:GO

Attached a +tid,+d3d,+wgl log on Counter Strike: Global Offensive with the diagnostics patch from attachment 47866 [details]
It only appears to trigger those diagnostic lines twice through the whole log.
The log is 1.3 GiB when uncompressed.

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.

*** Bug 35855 has been marked as a duplicate of this bug. ***

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)

Link to a log with +seh,+tid,+win,+wgl,+d3d on CS:GO
https://www.dropbox.com/s/hhjq3dvg4qgf1bz/csgo_log2.7z
(placing on dropbox as it is over the max attachment size limit)

Also, should note that on CS:GO, to trigger it, the game has to be run in the "fullscreen windowed" mode and have "Multicore Rendering" set to Enabled.

(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.

(In reply to Gediminas Jakutis from comment #22)
> Link to a log with +seh,+tid,+win,+wgl,+d3d on CS:GO
> https://www.dropbox.com/s/hhjq3dvg4qgf1bz/csgo_log2.7z
> (placing on dropbox as it is over the max attachment size limit)
> 
> Also, should note that on CS:GO, to trigger it, the game has to be run in
> the "fullscreen windowed" mode and have "Multicore Rendering" set to Enabled.

The two logs from CS:GO show that it has a different underlying cause.  Apparently, sometimes when you Alt-Tab away and back, CS:GO destroys its window.  I'm not sure why or what it plans to do after that.

Prior to commit 4c4552c5, wined3d would essentially not notice that the window had been destroyed.  Its current context would be left current and it would not check the window's pixel format.  Somehow rendering would continue working.  I suspect that the graphics driver keeps the GLX drawable (the window) extant as long as a context that targets it is current.  gl*() functions and glXSwapBuffers() keep working.

After that commit, wined3d calls GetPixelFormat() to check the pixel format of the window on entry.  Since the window has been destroyed from the Win32 point of view, this fails and returns 0.  Wined3d figures that it therefore has to set the pixel format and furthermore set up the GL context.  Setting the pixel format also fails because the Win32 window has been destroyed.  That causes wined3d to create a new off-screen window and set the context to target that.  From that point on, most rendering is not displayed.

I'm not sure why a) the window doesn't just vanish from the screen, or b) why some rendering sometimes displays after that point.

Since the issue with CS:GO is so different from Path of Exile and Anno 1602, I may need to re-separate them.

Created attachment 47883 [details]
Patch to avoid thrashing the pixel format when the game didn't set one

This patch may help with the pixel format thrashing issue that affects PoE and Anno 1602.  I don't expect it to help with CS:GO.  I'm not sure about the others since I don't know exactly what's going on with them.

I tested CS:GO on latest git with attachment 47883 [details] and indeed, as expected, it did not fix the problem.
Although it did alter it a bit, so I should inform about my findings: it now stutters somewhat less. Without the patch from attachment 47883 [details] the game stutters so much for me, it's nearly unplayable. While with the patch, it stutters less enough to be _kinda_ playable if having no other choice.

The new patch fixes Anno 1602 for me.

Fixed when using patch from attachment 47883 [details]. Thanks!

(In reply to Frédéric Delanoy from comment #28)
> Fixed when using patch from attachment 47883 [details]. Thanks!

Fixed for Path of Exile to be complete

Yes, patch from attachment 47883 [details] fixes flickering and slowdown in Crysis 1.

Crysis 2 is also affected by this bug. After game loaded main menu it turns black and stops to respond. Proposed patch partially fixes this problem. Game become playable but hangs after player's death.

Also, proposed patch doesn't fixes stuttering in Splinter Cell: Blacklist.

Created attachment 47937 [details]
Another try at deferring recreation of the drawable

Thanks, everybody, for the testing with attachment 47883 [details].  The fact that it helped with some games is useful to confirm my theory of the problem.  I don't think it's the proper solution though.

I've attached a revamped version of attachment 47808 [details] (with the diagnostics from attachment 47866 [details] included, too).  Since that didn't fix the problem for most of you, this probably still won't fix the problem.  But I've added more debug tracing to hopefully help explain why.

So, please apply this patch on top of current git (wine-1.7.15-133-g62f7ba2) and collect another +tid,+d3d,+wgl log.  Again, exit the game as soon as you see the problem (or are sure it's gone) to keep the log short.

I don't expect this to help with the CS:GO problem, so no need to retest that.

Thanks!

For those interested, the theory behind this patch is to decouple the thrashing of the pixel format from the destruction and recreation of the drawable in the X11 driver (as described in comment 23).  When the pixel format is changed, the X11 driver now makes note of that but doesn't recreate its drawable immediately.  Instead, it waits until the drawable is truly needed.  At that time, if the pixel format has been changed back so that it's compatible with the drawable again, then the drawable is just kept as-is.

(In reply to Ken Thomases from comment #32)
> Created attachment 47937 [details]
> Another try at deferring recreation of the drawable
> 
> Thanks, everybody, for the testing with attachment 47883 [details].  The
> fact that it helped with some games is useful to confirm my theory of the
> problem.  I don't think it's the proper solution though.
> 
> I've attached a revamped version of attachment 47808 [details] (with the
> diagnostics from attachment 47866 [details] included, too).  Since that
> didn't fix the problem for most of you, this probably still won't fix the
> problem.  But I've added more debug tracing to hopefully help explain why.
> 
> So, please apply this patch on top of current git (wine-1.7.15-133-g62f7ba2)
> and collect another +tid,+d3d,+wgl log.  Again, exit the game as soon as you
> see the problem (or are sure it's gone) to keep the log short.
> 
> I don't expect this to help with the CS:GO problem, so no need to retest
> that.
> 
> Thanks!
> 
> For those interested, the theory behind this patch is to decouple the
> thrashing of the pixel format from the destruction and recreation of the
> drawable in the X11 driver (as described in comment 23).  When the pixel
> format is changed, the X11 driver now makes note of that but doesn't
> recreate its drawable immediately.  Instead, it waits until the drawable is
> truly needed.  At that time, if the pixel format has been changed back so
> that it's compatible with the drawable again, then the drawable is just kept
> as-is.

Works for Path of Exile.

Created attachment 47938 [details]
Log for Path of Exile with attachment 47937 [details]

(In reply to Xavier Vachon from comment #33)
> (In reply to Ken Thomases from comment #32)
> > Created attachment 47937 [details]
> > Another try at deferring recreation of the drawable
> > 
> > Thanks, everybody, for the testing with attachment 47883 [details].  The
> > fact that it helped with some games is useful to confirm my theory of the
> > problem.  I don't think it's the proper solution though.
> > 
> > I've attached a revamped version of attachment 47808 [details] (with the
> > diagnostics from attachment 47866 [details] included, too).  Since that
> > didn't fix the problem for most of you, this probably still won't fix the
> > problem.  But I've added more debug tracing to hopefully help explain why.
> > 
> > So, please apply this patch on top of current git (wine-1.7.15-133-g62f7ba2)
> > and collect another +tid,+d3d,+wgl log.  Again, exit the game as soon as you
> > see the problem (or are sure it's gone) to keep the log short.
> > 
> > I don't expect this to help with the CS:GO problem, so no need to retest
> > that.
> > 
> > Thanks!
> > 
> > For those interested, the theory behind this patch is to decouple the
> > thrashing of the pixel format from the destruction and recreation of the
> > drawable in the X11 driver (as described in comment 23).  When the pixel
> > format is changed, the X11 driver now makes note of that but doesn't
> > recreate its drawable immediately.  Instead, it waits until the drawable is
> > truly needed.  At that time, if the pixel format has been changed back so
> > that it's compatible with the drawable again, then the drawable is just kept
> > as-is.
> 
> Works for Path of Exile.

Actually, change that. The game loads and technically works fine, but the FPS in game is down to 2-3 fps. Therefore way too slow to be playable. Uploaded your log with the last 100000 lines of what the output produced. Hopefully this will give you the info that you need.

Age of Wonders III appears to be affected in the exact same way as CS:GO is.
(in AoW3, using "borderless" mode. Which is basically the same thing as "Fullscreen Windowed" for CS:GO that was mentioned in one of the previous comments.)

Created attachment 47939 [details]
+tid,+d3d,+wgl log with patch from attachment 47937 [details] on Anno 1602

attachment 47937 [details] fixes the blank screen and the game is playable. But the main menus have odd input lag. It reacts instantly to most mouse clicks, while sometimes not reacting for several seconds.

Attached trace came from one run where I managed to hit a few input lags and one quite large 2-3s lag during the end.

Created attachment 47956 [details]
+tid,+d3d,+wgl log on Path of Exile wine 62f7ba2 + patch from attachment 47937 [details] (part 1)

With this new patch, on PoE, no flickering but only black screen + moveable mouse pointer (music playing).

Log splitted due to maximum bugzilla attachment size (use 'cat' to reconstruct)

Created attachment 47957 [details]
+tid,+d3d,+wgl log on Path of Exile wine 62f7ba2 + patch from attachment 47937 [details] (part 2)

Created attachment 48193 [details]
Patch implementing WGL_WINE_surface extension

I am attaching a new, BIG patch.  This is a mostly-complete implementation of an overall fix for issues between WineD3D and WGL.  If you care about the background, you can check out this wine-devel email thread: <http://www.winehq.org/pipermail/wine-devel/2014-January/102637.html>.

It should also fix this issue in all of its manifestations.

Please give it a try and let me know whether or not it fixes this bug.  I am also interested in whether it causes new problems, but such issues would not be appropriate for Bugzilla (since it involves patches which aren't in Wine).  So, please send such reports to the email thread linked above or directly to me.

(In reply to Ken Thomases from comment #39)
> Created attachment 48193 [details]
> Patch implementing WGL_WINE_surface extension
> 
> I am attaching a new, BIG patch.  This is a mostly-complete implementation
> of an overall fix for issues between WineD3D and WGL.  If you care about the
> background, you can check out this wine-devel email thread:
> <http://www.winehq.org/pipermail/wine-devel/2014-January/102637.html>.
> 
> It should also fix this issue in all of its manifestations.
> 
> Please give it a try and let me know whether or not it fixes this bug.  I am
> also interested in whether it causes new problems, but such issues would not
> be appropriate for Bugzilla (since it involves patches which aren't in
> Wine).  So, please send such reports to the email thread linked above or
> directly to me.

Path of exile works well with this patch.

This patch fixed stuttering in Splinter Cell: Blacklist.

(In reply to Xavier Vachon from comment #40)
> (In reply to Ken Thomases from comment #39)
> > Created attachment 48193 [details]
> > Patch implementing WGL_WINE_surface extension
> > 
> > I am attaching a new, BIG patch.  This is a mostly-complete implementation
> > of an overall fix for issues between WineD3D and WGL.  If you care about the
> > background, you can check out this wine-devel email thread:
> > <http://www.winehq.org/pipermail/wine-devel/2014-January/102637.html>.
> > 
> > It should also fix this issue in all of its manifestations.
> > 
> > Please give it a try and let me know whether or not it fixes this bug.  I am
> > also interested in whether it causes new problems, but such issues would not
> > be appropriate for Bugzilla (since it involves patches which aren't in
> > Wine).  So, please send such reports to the email thread linked above or
> > directly to me.
> 
> Path of exile works well with this patch.

Confirming.

attachment 48193 [details] fixes Anno 1602

attachment 48193 [details] appears to fix the problem with CS:GO
Cannot check whether attachment 48193 [details] fixes the problem for Age of Wonders 3 - AOW3 doesn't run with this patch for me, thus, I cannot see if it does.

>Cannot check whether attachment 48193 [details] fixes the problem for Age of Wonders 3 - AOW3 doesn't run with this patch for me, thus, I cannot see if it does.

After using a dirty workaround to make AoW3 run with the patch, can see it does indeed fix the problem for AoW3.

attachment 48193 [details] fixes the issue in Warframe.

attachment 48193 [details] applied to wine 1.7.17 fixes the problem for me in CS:GO. I am also using Maarten's multimedia patch (wine-multimedia in AUR).  The problem is, upgrading to wine 1.7.17 cut my framerate from 120 to around 40, making the game almost unplayable.  I also upgraded to nvidia 337.12 around the same time, so I will downgrade wine and test if the slowdown was caused by nvidia or wine.

(In reply to Kyle Bradfield from comment #47)

>upgrading to wine 1.7.17 cut my framerate from 120 to around 40
Upgrading from what version?

Compared to pre-regression Wine (Wine prior the 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 commit that started this) and with 1.7.17  && latest git, with attachment 48193 [details] I actually see a slight framerate increase, even. And I too upgraded my Nvidia drivers to 337.12
So, at least on my end, I don't see any kind of new slowdowns, to the contrary, even.

With 1.7.13, everything worked great.  Then I upgraded to 1.7.16 which caused this stuttering issue, but single threaded rendering performance was still acceptable.  Then I upgraded to 1.7.17 and saw the performance drop.  So I applied the patch and turned multicore rendering back on.  The stuttering problem was fixed, but performance was still low.

I will try the wine-multimedia-csmt AUR package which is still at 1.7.15 and see if that restores the performance.

When playing on 1.7.17, I had two vbox machines running plus kdevelop and a dozen or so Chromium tabs open. However, I have 32GB of RAM, core i5-2500k, and a GTX 660.  I usually had all those same things open when I ran the game before, and it didn't seem to have much impact on performance.  Although I guess I should try playing on wine 1.7.17 with nothing else running to be fair.  BTW, I always disable kwin compositing before starting the game.

Will do more testing when I get a chance and report back.

Did a fresh reboot and tried playing on 1.7.15 and 1.7.17.  Performance was low on both, so I guess I have something else going on not related to wine, maybe the new nvidia 337.12 driver or some other update that happened around the same time I upgraded to wine 1.7.17.

Patch from attachment 48193 [details] applied to wine 1.7.17 fixes flickering and 
slowdown in Crysis 1 caused by commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376.

The windows version in my steam prefix somehow got changed to XP. I changed it back to 7 and cs:go is now performing well again with wine 1.7.17, multicore rendering, and attachment 48193 [details]. Thanks for the patch, and sorry for bringing in an unrelated issue.

This also affects Dark Souls II, although it also needs StrictDrawOrdering to reduce the flickering even further. It doesn't quite solve all of it, though. I hope this patch can be combined with CSMT soon, as I suspect it is needed to get the game close to glitch-free. The game doesn't work with older versions of Wine before 1.7.16 or so, because of some fixes in the interim.

(In reply to Xavier Vachon from comment #40)
> (In reply to Ken Thomases from comment #39)
> > Created attachment 48193 [details]
> > Patch implementing WGL_WINE_surface extension

> Path of exile works well with this patch.

Thank you so much Ken, finally PoE works better.

Created attachment 48381 [details]
fps dropping shocked ground

(In reply to Ken Thomases from comment #39)
> Created attachment 48193 [details]
> Patch implementing WGL_WINE_surface extension
> Please give it a try and let me know whether or not it fixes this bug.  I am
> also interested in whether it causes new problems, but such issues would not
> be appropriate for Bugzilla (since it involves patches which aren't in
> Wine).  So, please send such reports to the email thread linked above or
> directly to me.

The only thing I’ve expected with the new patch is that the frame dropping still occours on shocked ground.

Created attachment 48382 [details]
fps dropping shocked ground with F1

Sorry, picture with F1 missing.

(In reply to none2366811 from comment #55)

> The only thing I’ve expected with the new patch is that the frame dropping
> still occours on shocked ground.

Is that a symptom that was introduced by either commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 or by my patch?  Or are you simply reporting that this was a long-standing problem that's still there?

No, it got a bit better with the patch, from unplayable 5 - 10 FPS to rather stable 20 FPS but it’s still laggy.

The patch does not apply cleanly on current master any longer.

There is a merge conflict in dlls/winex11.drv/opengl.c

After playing with many people in PoE, I think the FPS drop is also based on how they throw people from diffent server locations together after joining a group. So you can end up with people from Australia/Asia/America, which will cause of course a lag. Beside that, there’s the OpenGL/DirecX issue.

Created attachment 48503 [details]
Rebased implementation of WGL_WINE_surface extension

(In reply to Christoph Korn from comment #59)
> The patch does not apply cleanly on current master any longer.
> 
> There is a merge conflict in dlls/winex11.drv/opengl.c

I have attached a new version of the patch.  It applies to current git.  It also fixes some problems found by you guys testing.  Thanks!

It also has minor improvements to management of the full-screen window.  Switching focus to that window should be more reliable.  That window will reposition itself more promptly on a resolution change.  It has a title and icon to match the normal app window (which is still also present; that will eventually be fixed).

There's also a new feature for those of you using a compositing window manager under X11.  The full-screen window requests to bypass the compositor, which may improve performance.

Sadly, this work has hit a bump in the road on the way to getting into Wine.  Alexandre is doubtful that the design is right.  So, it may be some time before it gets accepted.

(In reply to Ken Thomases from comment #61)
> I have attached a new version of the patch.  It applies to current git.  It
> also fixes some problems found by you guys testing.  Thanks!

I found a problem with this patch.

When fullscreen app changes screen refresh rate, it creates new window instead to replace old one. As a result, 2 windows appears, one of them is black.

http://imgur.com/wgZ9fUT

(In reply to Yuri Shishenko from comment #62)

Are You sure the black screen isn't present before changing the refresh rate?
Because, currently, it is supposed to create two "windows" for fullscreen games/programs and render to the 2nd one while the first window is simply black. It puts the 2nd window to the foreground, so normally this should not be noticed.

(In reply to Gediminas Jakutis from comment #63)
> (In reply to Yuri Shishenko from comment #62)
> 
> Are You sure the black screen isn't present before changing the refresh rate?
> Because, currently, it is supposed to create two "windows" for fullscreen
> games/programs and render to the 2nd one while the first window is simply
> black. It puts the 2nd window to the foreground, so normally this should not
> be noticed.

Indeed. Just checked for few other games. Black window appears without changing refresh rate.

Its so weird and annoying.
Gnome-shell constantly sends notifications that black window hangs and asks to kill it.
Pretty much every game is affected.

Anno 1602 works fine with the new patch. But wine terminates when I try to alt-tab out of it. If I try to switch to the black window, it works fine. But trying to switch to another window just make the game screen reappear, trying to interact with it will terminate wine with these messages:
fixme:d3d_surface:wined3d_surface_blt Can't handle WINEDDBLT_ASYNC flag.
fixme:d3d_surface:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit. (appears several times)
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0x3600008
  Serial number of failed request:  260
  Current serial number in output stream:  261

This is using KWin on an up-to-date arch.

attachment 48503 [details] seems to fix all the problems with CS:GO in "fullscreen windowed" mode and returns the performance back to the same level it was before 
4c4552c5a1910a9d5adf8eccff0ac62d89ffe376


Seems to fix problems with Age of Wonders III, too. Albeit, while closing AoW3 when ran in Borderless mode, it generates:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  2082
  Current serial number in output stream:  2082

On user request I've compiled a version of wine-compholio for Archlinux which includes the proposed patch by Ken (http://bugs.winehq.org/attachment.cgi?id=48503&action=diff) - and I thought it is probably useful to share it here for other people that want to try it out. ;-)

You can find the packages here:
i686: http://cache.fds-team.de/testing/arch-i686/20140525-1751/
x86_64: http://cache.fds-team.de/testing/arch-x86_64/20140525-1731/

Please note that this version also adds (besides Kens patch) a lot of other custom patches (see https://github.com/compholio/wine-compholio-daily), so please don't report bugs encountered with this version to the wine bugtracker.

The version will be installed to /opt/wine-compholio/bin/wine, so it can also be installed together with the regular version.

It happens to me with age of empires ONLY USING NVIDIA PROPIETARY DRIVERS but not with noevau, or intel drivers...

*** Bug 36530 has been marked as a duplicate of this bug. ***

(In reply to Sebastian Lackner from comment #67)
> On user request I've compiled a version of wine-compholio for Archlinux
> which includes the proposed patch by Ken
> (http://bugs.winehq.org/attachment.cgi?id=48503&action=diff) - and I thought
> it is probably useful to share it here for other people that want to try it
> out. ;-)

Tried out the compiled version for x86_64 and it's working great.  I get noticeably higher FPS in CS:GO with this package over the wine-multimedia package I compiled from AUR.

*** Bug 36366 has been marked as a duplicate of this bug. ***

Just completed the campaign of Crysis 2 Maximum Edition (Origin) using Ken's WGL_WINE_surface extension patch (1920x1080, GTX 660M, nvidia 331.67, Wine 1.7.20).

Some end-of-level cut scenes did stutter quite a bit (if they didn't stutter right from the start, they would work 100%), but it seemed random as to whether it would happen. I could only produce it occasionally during the game. Selecting the unlocked cut-scene from the game menu always worked (although those don't play back in 100% full screen like they do at the end of a level).

Without the patch the game is unplayable - I can't even use the main menu. Since I've never even been able to get to an in-game cut-scene using recent releases of Wine until this patch, it's even possible that the occasional stuttering I'm seeing there is a different bug.

*** Bug 36986 has been marked as a duplicate of this bug. ***

Created attachment 49133 [details]
wine debug output log with Ken's Rebased WGL_WINE patch

I can confirm that "Rebased implementation of WGL_WINE_surface extension" patch fixed my report at Bug #36986 with the last wine 1.7.23, but that was good news... and now we came to bad - after this patch many games don't load at all in Fullscreen mode (windowed seems works) - sometimes I see infinite "Loading...", sometimes it is just black screen. The sound works as usual - I can hear the normal sound intro. 

I attached the debug log for this new issue.

*** Bug 36987 has been marked as a duplicate of this bug. ***

I can confirm that "Rebased implementation of WGL_WINE_surface extension" patch fixed my report at Bug #36987 with the last wine 1.7.23, but that was good news... and now we came to bad - after this patch many games don't load at all in Fullscreen mode (windowed seems works) - sometimes I see infinite "Loading...", sometimes it is just black screen. The sound works as usual - I can hear the normal sound intro. 

I attached the debug log for this new issue.

Comment on attachment 49133 [details]
wine debug output log with Ken's Rebased WGL_WINE patch

>fixme:iphlpapi:NotifyAddrChange (Handle 0xcce308, overlapped 0xcce320): stub
>fixme:iphlpapi:NotifyAddrChange (Handle 0xdce8f0, overlapped 0xdce8fc): stub
>fixme:mountmgr:harddisk_ioctl Unsupported ioctl 74080 (device=7 access=1 func=20 method=0)
>fixme:win:EnumDisplayDevicesW ((null),0,0x33f278,0x00000000), stub!
>ALSA lib pcm_hw.c:1667:(_snd_pcm_hw_open) Invalid value for card
>fixme:dsound:IDirectSoundBufferImpl_SetFX (0x1c2930,0,(nil),(nil)): stub

I'd like to add that I encountered a similar problem with the same regression SHA1 running Star Wars Galactic Battlegrounds, as reported in bug 36900.

I found that attachment 48503 [details] is an improvement, but is not a perfect fix, as described in bug 36900, comment 3.

(In reply to Sebastian Lackner from comment #67)
> On user request I've compiled a version of wine-compholio for Archlinux
...
> The version will be installed to /opt/wine-compholio/bin/wine, so it can
> also be installed together with the regular version.

i managed to install it on my computer (an made a post here
https://appdb.winehq.org/objectManager.php?sClass=version&iId=25078
to describe how i did it).

As i'm not used to running multiple versions of wine together i'd like help on the appdb page (i'm gonna get flamed here in no time because the bug report isn't the place for such talk).

*** Bug 37206 has been marked as a duplicate of this bug. ***

Created attachment 49551 [details]
Attachment #48503 [details] failure  log

Attachment #48503 [details] does not apply on top of the latest wine, and the bug is still prevalent in current git. Attached a patch log showing where the hack fails to apply.

Created attachment 49567 [details]
updated patch

I updated the patch. Now it applies clearly against 1.7.26

Since I won't be working on the proper solution for this in the foreseeable future, I have submitted reverts of the original problem commit and some related commits:

http://source.winehq.org/patches/data/106532
http://source.winehq.org/patches/data/106534
http://source.winehq.org/patches/data/106533
http://source.winehq.org/patches/data/106535
http://source.winehq.org/patches/data/106536

(In reply to Mikhail T. from comment #83)
> Created attachment 49567 [details]
> updated patch
> 
> I updated the patch. Now it applies clearly against 1.7.26

Fails in 1.7.27

[xavier@xavier-pc wine-git]$ patch -p1 < 49567-35718.patch 
patching file dlls/opengl32/make_opengl
patching file dlls/opengl32/opengl_ext.c
patching file dlls/opengl32/opengl_ext.h
patching file dlls/opengl32/opengl_norm.c
patching file dlls/opengl32/wgl.c
patching file dlls/user32/user32.spec
patching file dlls/user32/win.c
patching file dlls/user32/win.h
patching file dlls/user32/winpos.c
patching file dlls/wined3d/arb_program_shader.c
Hunk #1 FAILED at 7663.
1 out of 1 hunk FAILED -- saving rejects to file dlls/wined3d/arb_program_shader.c.rej
patching file dlls/wined3d/context.c
patching file dlls/wined3d/device.c
Hunk #1 succeeded at 751 (offset 2 lines).
Hunk #2 succeeded at 4619 (offset 119 lines).
patching file dlls/wined3d/directx.c
patching file dlls/wined3d/surface.c
Hunk #4 FAILED at 3921.
1 out of 4 hunks FAILED -- saving rejects to file dlls/wined3d/surface.c.rej
patching file dlls/wined3d/swapchain.c
patching file dlls/wined3d/wined3d_gl.h
patching file dlls/wined3d/wined3d_private.h
Hunk #1 succeeded at 1125 (offset 1 line).
Hunk #2 succeeded at 2320 (offset 4 lines).
Hunk #3 succeeded at 2695 (offset 18 lines).
Hunk #4 succeeded at 2708 (offset 18 lines).
patching file dlls/winemac.drv/cocoa_window.m
patching file dlls/winemac.drv/macdrv.h
patching file dlls/winemac.drv/macdrv_cocoa.h
patching file dlls/winemac.drv/mouse.c
patching file dlls/winemac.drv/opengl.c
patching file dlls/winex11.drv/desktop.c
patching file dlls/winex11.drv/event.c
patching file dlls/winex11.drv/keyboard.c
patching file dlls/winex11.drv/mouse.c
patching file dlls/winex11.drv/opengl.c
patching file dlls/winex11.drv/window.c
patching file dlls/winex11.drv/x11drv.h
patching file dlls/winex11.drv/x11drv_main.c
patching file include/wine/wgl_driver.h
patching file server/window.c

 
> Fails in 1.7.27
As I wrote above the patch is against 1.7.26 and it not guarantied  neither to apply nor to compile with newer or older versions

It is worth noting that a small patch from Comment#25
(https://bugs.winehq.org/attachment.cgi?id=47883)
still fixes this bug in Crysis 1 for Wine 1.7.27.

Created attachment 49679 [details]
patch for 1.7.27

Patch worked great for Roller Coaster Tycoon 2 with 1.7.21 but doesn't apply against the recently released 1.7.28. The 1.7.27 patch also failed to apply for me.

What is preventing this patch from being applied on mainline?

Created attachment 49744 [details]
Terminal output with Wine 1.7.28

I'm seeing the black screen issue in Path of Exile and The Forest too. But setting OffscreenRenderingMode to backbuffer in Software\\Wine\\Direct3D works as a workaround but causes to look The Forest and parts of Path of Exile like they have got too many contrast. In the attachments is a log from The Forest if the black screen appears.

(In reply to Lee Trager from comment #89)
> What is preventing this patch from being applied on mainline?

As I’ve understood it’s the compatibility with old (x86) machines.

As mentioned in comment 89, the hack could use a rebase against the current version of wine. As of today, it should be 1.7.32.

Why don't you just revert the patches which caused the flickering and drawing issues? Even the latest patchset by Ken Thomases didn't solve all issues for me, and as he stopped working on it, it might be easier to restore the old (not completely correct but at least functional) state.

The patchset to revert these changes is also part of Wine Staging:
https://github.com/wine-compholio/wine-staging/tree/master/patches/wined3d-Revert_PixelFormat

Created attachment 50151 [details]
patch against wine 1.7.30

Created attachment 50154 [details]
patch against wine-1.7.31-csmt

This is a patch derived from the one from Comment#94 but
it is intended to be applied against recent Wine-CSMT
(https://github.com/stefand/wine/archive/master.zip)
which is correspondent to version 1.7.31.

I have tested that the WGL patch is compatible with the CSMT
patch and not only fixes the Crysis 1 slowdown bug but also
adds 2-5 frames per second to such games as TES4:Oblivion
and TES5:Skyrim as compared to the pure CSMT. On the other
hand the patched Wine refuses to launch several games
(Half Life 1, for example).

Created attachment 50865 [details]
patch against wine 1.7.33

patch against wine 1.7.33

How to update patch against wine 1.7.38?
I'm having trouble with dlls/winemac.drv/opengl.c and dlls/winex11.drv/opengl.c.
Do I just add surface everywhere that pbuffer is used?

(In reply to Martin Fontaigne from comment #98)
> How to update patch against wine 1.7.38?
> I'm having trouble with dlls/winemac.drv/opengl.c and
> dlls/winex11.drv/opengl.c.
> Do I just add surface everywhere that pbuffer is used?

Never mind. I just found the failed hunk location (it was earlier than the previous hunk.)

Resident Evil 5 Gold Edition Affected too

Nvidia Drivers 349.12
Linux Mint 17 XFCE Edition 64Bit - Kernel 3.18.0.31
CPU: INTEL Pentium G3220 (Haswell 22nm) 3.0Ghz (Dual-Core) Stock Clock
MEM: 8GB DDR3 1333 (2x4) Patriot value (128 bit dual channel: 21.3 gb/s)
GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s)
BOARD: MSI H81M E33

I'm using now Wine 1.7.38 and haven't seen the black screen issue anymore in The Forest for a while. But the game is still in early development and maybe something on the game changed that fixed this there.

Sins of a Solar Empire: Rebellion is also affected when using the wine 1.7.42.

Currently, I've kept a copy of wine 1.7.24 until this bug is officially fixed since I can patch wine using the attachment in comment #61 and view the game just fine.

System data:
Arch Linux 64bit
nvidia drivers v349.16 w/nVidia GeForce GT 630
AMD Athlon(tm) II X4 635 Processor
8GB RAM (don't know model of RAM sticks)

Created attachment 51412 [details]
patch against wine 1.7.41

Path of Exile still needs patched wine.
The patch against wine 1.7.41 attached

(In reply to shadowkyogre.public from comment #102)
> Sins of a Solar Empire: Rebellion is also affected when using the wine
> 1.7.42.
> 
> Currently, I've kept a copy of wine 1.7.24 until this bug is officially
> fixed since I can patch wine using the attachment in comment #61 and view
> the game just fine.
> 
> System data:
> Arch Linux 64bit
> nvidia drivers v349.16 w/nVidia GeForce GT 630
> AMD Athlon(tm) II X4 635 Processor
> 8GB RAM (don't know model of RAM sticks)

Confirming that SoSE: Rebellion is suffering from slowdown. Cannot confirm that it is after 1.7.245, but definelty I started to experience it in whole 1.7.3x versions...

This issue continues for Path of Exile on WINE 1.7.44.

I'm also seeing this with Enemy Front (which uses CryEngine 3) and Wine 1.7.45.

I can confirm that this bug makes Starcraft: Brood War unplayable. The patch brings it back to normal again though.

*** Bug 35950 has been marked as a duplicate of this bug. ***

*** Bug 16766 has been marked as a duplicate of this bug. ***

(In reply to Ken Thomases from comment #23)
> 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.

Why does the X11 driver have to destroy and recreate the window just to change the pixel format? I have been looking through dlls/winex11.drv/opengl.c and as far as I can tell, set_pixel_format calls set_win_format, which tears down and recreates the X window but does not actually use the pixel format except to set the value of a Wine-specific window struct member.

Are you sure that we couldn't insert a shortcut into the X11 driver?

(In reply to Alex Henrie from comment #110)
> (In reply to Ken Thomases from comment #23)
> > 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.
> 
> Why does the X11 driver have to destroy and recreate the window just to
> change the pixel format?

The pixel format dictates the fbconfig. The fbconfig dictates the visual. The visual is a property of the window set at creation.

The fbconfig or visual is also used when creating the GLX rendering context.

When you attempt to make a GLX context current for a drawable, the visual of the context and drawable must match or you get an error.

> I have been looking through
> dlls/winex11.drv/opengl.c and as far as I can tell, set_pixel_format calls
> set_win_format, which tears down and recreates the X window but does not
> actually use the pixel format except to set the value of a Wine-specific
> window struct member.

create_gl_drawable() passes the visual to create_client_window().

(In reply to Ken Thomases from comment #111)
> The pixel format dictates the fbconfig. The fbconfig dictates the visual.
> The visual is a property of the window set at creation.

OK, thanks for the answer. I read the wine-devel discussion from May 2014 as well, and it sounds like we need more tests to determine whether native d3d supports having multiples surfaces per window. If it does, then we can add multiple surface support because some applications might need it anyway, then capitalize on that feature to give user32 and d3d separate surfaces to avoid context switching. If native d3d does not permit multiple surfaces, then maybe we can cache the old X window in the X11 driver and just move it to the front if the previous pixel format is needed again.

Unfortunately, I do not know how to write the tests we need for this. I might be able to come up with something eventually, but it would be better if someone familiar with d3d tackled this.

Sorry if these seem like stupid questions...this bug has attracted my interest not because I particularly like messing with d3d code, but rather because the problem here is so severe and there are a large number of applications affected.

Created attachment 52342 [details]
patch against wine 1.7.48

After upgrading from stable 1.6 release to 1.7.51, Rollercoaster Tycoon 2 no longer stutters. Thank you very much for the patch!

(In reply to marek.timura from comment #114)
> After upgrading from stable 1.6 release to 1.7.51, Rollercoaster Tycoon 2 no
> longer stutters. Thank you very much for the patch!

Since this bug did not appear until 1.7.13, and is still present for me in 1.7.51, I think you were seeing a different bug. But I'm glad that the graphics in the 1.7 series seems to be working better than 1.6 in some cases.

Is this bug present on Mac? I've noticed something similar on mac with crisis 2, but in wine staging.

*** Bug 39542 has been marked as a duplicate of this bug. ***

Henri's commit <http://source.winehq.org/git/wine.git/?a=commit;h=c92451f295242110bf016facf0e80564f3643d94> should improve this in most cases.

Please retest with current git or Wine 1.7.55 or later and report results.

(In reply to Ken Thomases from comment #118)
> Henri's commit
> <http://source.winehq.org/git/wine.git/?a=commit;
> h=c92451f295242110bf016facf0e80564f3643d94> should improve this in most
> cases.
> 
> Please retest with current git or Wine 1.7.55 or later and report results.


With your commit has fixed in dark souls

Gameplay video

https://www.youtube.com/watch?v=qFlJe55dA9o


System Specs

Wine-b53256b

Nvidia Drivers 358.09
Linux Mint 17.2 Raffaela XFCE Edition 64Bit - Kernel 4.0.0-040000-generic (ubuntu mainline)
CPU: INTEL Pentium G3258 (22nm) 4.1Ghz + Artic Cooling Alpine 11 Plus
MEM: 8GB DDR3 1333 (2x4) Patriot value (dual channel: 21.3 gb/s)
GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s)
MAINBOARD: MSI H81M E33


Slso test dinasty warriors orochi and fixed too, maybe more later upload various test with titles affected with this issue

However in dark souls 2 dont work, game still have flickering in window and fullscreen mode but wrc 1, wrc 2, roller coaster tycoon 1 and 2 works correctly

I can confirm that the commit from Comment #118 fixes
this bug for Crysis 1 (was tested with plain Wine 1.7.53).

Starcraft I is back to normal with Henri's patch, thanks.

As commented before wrc titles affected by this bug as corrected and roller coaster tycoon tiles affected also fixed


System Specs


Wine-Git

Nvidia Drivers 358.09
Linux Mint 17.2 Raffaela XFCE Edition 64Bit - Kernel 4.0.0-040000-generic (ubuntu mainline)
CPU: INTEL Pentium G3258 (22nm) 4.1Ghz + Artic Cooling Alpine 11 Plus
MEM: 8GB DDR3 1333 (2x4) Patriot value (dual channel: 21.3 gb/s)
GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s)
MAINBOARD: MSI H81M E33



This is some gameplay with this titles



Dinasty Warriors Orochi

https://www.youtube.com/watch?v=EICy1dCE2NE



WRC 1

https://www.youtube.com/watch?v=NVQA2phX_dw



WRC 2

https://www.youtube.com/watch?v=TLUrJURaN5M



WRC 3

https://www.youtube.com/watch?v=yaS-5FOyJBs



Roller Coaster Tycoon 1

https://www.youtube.com/watch?v=5_6ksfaO2EQ



Roller Coaster Tycoon 2

https://www.youtube.com/watch?v=Y6lmMFrQyn4

Path of Exile works fine now

Fixed for most apps. Please open new bugs if there are remaining issues.

*** Bug 38155 has been marked as a duplicate of this bug. ***

Closing bugs fixed in 1.8-rc1.

(In reply to mrdeathjr28 from comment #120)
> However in dark souls 2 dont work, game still have flickering in window and
> fullscreen mode but wrc 1, wrc 2, roller coaster tycoon 1 and 2 works
> correctly

Could you please test if the issue with Dark Souls 2 is still present? If yes, please open a new bug report for it, to ensure that this issue doesn't get lost. Please also test if the following patchset helps, which reverts most of the pixel format changes: https://github.com/wine-compholio/wine-staging/tree/master/patches/wined3d-Revert_PixelFormat

Tested darksouls II on wine 1.9.3 but error still present


System Specs


Nvidia Drivers 361.18
Linux Mint 17.2 Raffaela XFCE Edition 64Bit - Kernel 4.2.0-25 generic (ubuntu mainline) - P-State: Performance
CPU: INTEL Pentium G3258 (Haswell 22nm) 4.1Ghz + Artic Cooling Alpine 11 Plus
MEM: 8GB DDR3 1333 (2x4) Patriot value (dual channel: 21.3 gb/s)
GPU: Zotac Nvidia Geforce GT630 (GK208 28nm: 384 Shaders / 8 ROPS) Zone Edition Passive Cooling 2GB DDR3 1800Mhz 64Bit (14.4Gb/s)
MAINBOARD: MSI H81M E33


wine DarkSoulsII.exe
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
fixme:win:EnumDisplayDevicesW ((null),0,0x33f648,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f3d8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33ebb8,0x00000000), stub!
fixme:d3d:swapchain_init The application requested more than one back buffer, this is not properly supported.
Please configure the application to use double buffering (1 back buffer) if possible.
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0x142ce994): stub
fixme:thread:SetThreadIdealProcessor (0xfffffffe): stub

At now shows double buffer error (dark souls II force vsync????)

However some time ago stefan dosinger talks about as solve this problem using arb buffer storage extension

Maybe flickering have more relation with double buffer in this point

(In reply to mrdeathjr28 from comment #129)
> Tested darksouls II on wine 1.9.3 but error still present

Can you please open a new bug for that, as Sebastian already asked? This bug is closed.

Thanks.