http://bugs.winehq.org/show_bug.cgi?id=32058
Bug #: 32058 Summary: Guild Wars 2 launcher freezes/hangs (unable to launch game) Product: Wine Version: 1.5.15 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: x.egam.wodahs.x@gmail.com CC: julliard@winehq.org Classification: Unclassified
Once I updated wine to version 1.5.15, the Guild Wars 2 launcher can no longer launch the game because it just freezes/hangs. This was not an issue in 1.5.14, and in order to run the game for now I'm using wine 1.5.14 compiled from source.
In wine 1.5.14, the launcher is black (can't see UI at all, but it's still functional) unless using the -dx9single flag. Using -dx9single, the background is black instead of transparent but the UI inside is properly rendered. This information is important because, before submitting this bug report, I performed two separate git bisects between 1.5.14 and 1.5.15: one without any command-line parameters, and one using -dx9single.
Technical details follow:
=======================================================================
1) git bisect for running the game without any parameters: In the last good commit (8dcbeff760115834656f3f1fc85922e3a9af14d0), the launcher is still black but it still works. You cannot see the UI but by blindly logging in, the game does launch. In the first bad commit (f12c1c6630f0bf842dde9af10da4ab188ff16e94), the behavior is different from the wine 1.5.15 release and the other commits tested: here, instead of locking up, the window just disappears. It's still there, but I guess it's fully transparent. Because this leaves us even more "blind", I considered this "bad" in the git bisect, yielding the following result:
--- f12c1c6630f0bf842dde9af10da4ab188ff16e94 is the first bad commit commit f12c1c6630f0bf842dde9af10da4ab188ff16e94 Author: Alexandre Julliard julliard@winehq.org Date: Wed Sep 26 13:12:17 2012 +0200
winex11: Switch to an ARGB visual for layered windows with per-pixel alpha.
:040000 040000 e9933c28f3e50c52d2cee37a43b06a2f5cb5a497 3870099a31a68a69cd7c022857794700c2343aa9 M dlls ---
If, however, we consider f12c1c6630f0bf842dde9af10da4ab188ff16e94 "good" in the git bisect, we get:
--- d8247efd5ecb8c4604624eb2bbf47e194ce59e7e is the first bad commit commit d8247efd5ecb8c4604624eb2bbf47e194ce59e7e Author: Alexandre Julliard julliard@winehq.org Date: Thu Sep 27 20:47:08 2012 +0200
winex11: Take the alpha channel into account to compute the region of layered windows.
:040000 040000 3870099a31a68a69cd7c022857794700c2343aa9 d9ec62b63405f910db90b095145a7910cc124eef M dlls ---
In this case, the launcher does indeed lock up in the first bad commit (d8247efd5ecb8c4604624eb2bbf47e194ce59e7e).
2) git bisect for running the game using -dx9single: Using the -dx9single flag, we seem to be able to get to a later commit before it stops working (but does not work in the 1.5.15 release). In the last good commit (dbff4f422c943a837f0098e921f831eb4a94ac11), everything seems to be fine (when using the -dx9single flag) and even the transparency seems to be working. However, in the first bad commit (6f3b097a203d9ca248732cb45eed462599ca3af1), things start to lock up. This yields the following git bisect result:
--- 6f3b097a203d9ca248732cb45eed462599ca3af1 is the first bad commit commit 6f3b097a203d9ca248732cb45eed462599ca3af1 Author: Alexandre Julliard julliard@winehq.org Date: Wed Oct 3 00:09:01 2012 +0200
winex11: Fix a typo in the surface region computation with an alpha channel.
:040000 040000 fa11ac3c80763b81911ba999d8302029d2c6d147 566c9c06b11f8785c870a1e09ec53d42e13d1524 M dlls ---
http://bugs.winehq.org/show_bug.cgi?id=32058
x.egam.wodahs.x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |x.egam.wodahs.x@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=32058
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |6f3b097a203d9ca248732cb45ee | |d462599ca3af1
http://bugs.winehq.org/show_bug.cgi?id=32058
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|6f3b097a203d9ca248732cb45ee | |d462599ca3af1 |
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2012-10-26 04:30:55 CDT --- I don't think that's really a regression, it sounds like the window has never been drawn correctly.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #2 from x.egam.wodahs.x@gmail.com 2012-10-26 16:08:11 CDT --- Hi Alexandre,
Thanks for the reply. However, the regression I am reporting is not really about how the window looks / is drawn. You are right, it was not drawn correctly in 1.5.14. Rather, the issue I'm reporting is that in 1.5.15, the launcher locks up (freezes/hangs), leaving me unable to launch the game. In 1.5.14, I do not have this issue.
Is it possible that this only affects certain hardware? I can do my best to provide any useful info upon request, about my system or anything else related to this issue. Thanks again for your time.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2012-10-26 16:18:11 CDT --- Does it really lock up, or does it just display a transparent window and wait for a click? Do you get an error message?
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #4 from x.egam.wodahs.x@gmail.com 2012-10-26 16:46:29 CDT --- In 1.5.15, the window is visible, and has a transparent background (like it does on Windows), but it locks up. I don't see the login form (freezes before it loads) and even clicking the X inside the window on the top-right has no effect.
I don't get an error message in GW2 as it seems to just hang, but I can attach the output from wine (I can't say that I understand what it says).
Interestingly though, I just realized that if I leave it long enough (several minutes), the login form finally appears, but it is impossible (or very difficult) to login because it again appears frozen. Perhaps it is moving along, just incredibly slow? In 1.5.14, it only takes me about 3 or 4 seconds from the time I launch the game until I can start typing my login, and the input is smooth.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #5 from x.egam.wodahs.x@gmail.com 2012-10-26 16:48:30 CDT --- Created attachment 42267 --> http://bugs.winehq.org/attachment.cgi?id=42267 Output from wine-1.5.15
This is the output from wine when I try to launch Guild Wars 2 using wine-1.5.15.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #6 from x.egam.wodahs.x@gmail.com 2012-10-26 16:53:27 CDT --- Created attachment 42268 --> http://bugs.winehq.org/attachment.cgi?id=42268 Screenshot of launcher in wine-1.5.15
This is what I see when I try to launch Guild Wars 2 using wine-1.5.15. Don't be fooled by the "Downloading 0KB (0KB/sec)": I'm sure it's not a network issue as the launcher doesn't even respond to clicking on the "X".
http://bugs.winehq.org/show_bug.cgi?id=32058
nob.dir.info@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nob.dir.info@gmail.com
--- Comment #7 from nob.dir.info@gmail.com 2012-10-27 03:12:51 CDT --- I had such a problem when I disabled GLSL. Did you disable it by mistake?
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #8 from x.egam.wodahs.x@gmail.com 2012-10-27 11:04:27 CDT --- I believe GLSL is enabled. I did not disable it, but is there any way I can verify that it is enabled?
I remember, on an older system, I had once set UseGLSL="disabled" in HKEY_CURRENT_USER/Software/Wine/Direct3D of regedit in order to get something to work (a different game). However, on this system I haven't changed anything in regedit, so when I browse to HKEY_CURRENT_USER/Software/Wine there is no Direct3D directory.
Anything else I should check?
http://bugs.winehq.org/show_bug.cgi?id=32058
voidcastr voidcastr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |voidcastr@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #9 from x.egam.wodahs.x@gmail.com 2012-11-12 23:50:08 CST --- Hi,
I would just like to note that the same thing happens in 1.5.16 and in 1.5.17 (launcher freezes). Also, I tried reverting 6f3b097a203d9ca248732cb45eed462599ca3af1 by doing
git show 6f3b097a203d9ca248732cb45eed462599ca3af1 | patch -p1 -R
and then compiling. With the patch reverted, everything seems to work as long as I use -dx9single.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #10 from x.egam.wodahs.x@gmail.com 2012-11-25 16:34:36 CST --- So I'm currently using wine 1.5.18 with 6f3b097a203d9ca248732cb45eed462599ca3af1 reverted (the same commit mentioned in Comment 9, which is also the "first bad" commit of the 2nd git bisect from the initial report). Reverting this commit and compiling from source (and using -dx9single) is the only way I can run GW2 with wine 1.5.15 or higher. I know this isn't really news, just a status update I guess.
However, in an attempt to help get this fixed, I have taken a closer look at the diff of the commit
diff --git a/dlls/winex11.drv/bitblt.c b/dlls/winex11.drv/bitblt.c index ceecb0c..36e3ac9 100644 --- a/dlls/winex11.drv/bitblt.c +++ b/dlls/winex11.drv/bitblt.c @@ -1676,8 +1676,8 @@ static void update_surface_region( struct x11drv_window_surface *surface ) (surface->is_argb && !(bits[x] & 0xff000000)))) x++; start = x; while (x < width && - ((bits[x] & 0xffffff) != surface->color_key || - !(surface->is_argb && !(bits[x] & 0xff000000)))) x++; + !((bits[x] & 0xffffff) == surface->color_key || + (surface->is_argb && !(bits[x] & 0xff000000)))) x++; add_row( rgn, data, surface->header.rect.left + start, y, x - start ); } }
and can't help but wonder: was the condition in the while loop intentionally changed, or was the intention just to re-write it? I don't know enough about the wine source to understand the condition, but I would like to note that they are different, which is why reverting this commit makes GW2 work for me again.
If we simplify the condition by using letters a, b, c, d, then we can see the difference more easily: before: (x < width && (a != b || !(c && !d))) after: (x < width && !(a == b || (c && !d)))
In order for these to be the same, the second one would instead need to be for example (x < width && !(a == b && (c && !d)))
If the condition change was intentional, any ideas what may be the cause of the new one not working on my system? Here's some info (I can provide more info upon request) about my system: Operating System: Ubuntu 12.04 64-bit Graphics card: GeForce GTX 560 Ti NVIDIA Driver Version: 304.43
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2012-11-26 10:25:25 CST --- The previous version was wrong, that's why it was changed.
It worked probably because it resulted in a simpler region. It sounds like your window manager/compositor has trouble with a complex window region. You could try to disable compositing or use a different compositor.
http://bugs.winehq.org/show_bug.cgi?id=32058
--- Comment #12 from x.egam.wodahs.x@gmail.com 2012-11-26 23:37:08 CST --- Hi Alexandre,
I would like to thank you once again for taking the time to look into this, as well as for your suggestion in Comment 11. It looks like you have identified the problem. I performed all the tests above using Unity, but after reading that comment I discovered that (if I use -dx9single) it actually works for me in Gnome Shell!
Therefore, it seems that the issue is not in Wine, but rather something to do with Unity, or with something in my Unity setup (possibly the window manager/compositor, as you mentioned)
For future reference, I would like to note a couple new findings from the additional testing I've done, but at this point please feel free to close this bug as Invalid or whatever you think is best.
---
In Unity, it turns out that the issue seems to be more of a repainting issue than anything else. In the "locked up" window (I thought it was frozen, but actually it just wasn't repainting it seems) I blindly clicked on where the password field should be, typed my password, hit enter, and blindly clicked on where the "Play" button should be. The launcher still never repainted but sure enough the game launched. Also, finding where to click was made slightly easier by the fact that my mouse cursor actually did change even though the launcher itself didn't repaint.
http://bugs.winehq.org/show_bug.cgi?id=32058
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2012-11-27 04:15:38 CST --- Unity bug.
https://bugs.winehq.org/show_bug.cgi?id=32058
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=32058
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #15 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
https://bugs.winehq.org/show_bug.cgi?id=32058
LingM lingm+winebz@posteo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lingm+winebz@posteo.org
--- Comment #16 from LingM lingm+winebz@posteo.org ---
In Unity, it turns out that the issue seems to be more of a repainting issue than anything else. In the "locked up" window (I thought it was frozen, but actually it just wasn't repainting it seems) I blindly clicked on where the password field should be, typed my password, hit enter, and blindly clicked on where the "Play" button should be. The launcher still never repainted but sure enough the game launched. Also, finding where to click was made slightly easier by the fact that my mouse cursor actually did change even though the launcher itself didn't repaint.
Had the same bug with the Cinnamon DE in the past but it's been fixed for a few months now. Is this still an issue with Unity or has that also been fixed in the mean time?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla