https://bugs.winehq.org/show_bug.cgi?id=48293
Bug ID: 48293 Summary: Battle.net App lags when clicking UI elements Product: Wine-staging Version: 5.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: maciej.stanczew+b@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
This is a regression between 4.21 and 5.0rc1. On 4.21, clicking UI elements (e.g. Play button, friends list, or most noticeably selecting different games) was smooth and quick. On 5.0rc1 there is a 1-2 second lag after clicking when the whole UI is not responsive.
Reproduces both on NVIDIA (GTX 1060 with proprietary driver) and AMD (RX 560 with Mesa).
I've tested in a clean prefix, and narrowed it down to be between Staging commits 4522654f and 45d69ec4: Ok? Wine Staging wine --version good 5f0b5d3505 4522654f wine-4.21-347-g5f0b5d3505 (Staging) BAD 750d382f54 45d69ec4 wine-4.21-413-g750d382f54 (Staging) I'm currently doing bisection of Wine commits between the above two versions.
https://bugs.winehq.org/show_bug.cgi?id=48293
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
--- Comment #1 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Bisection results:
f2e5b8070776268912e1886d4516d7ddec6969fc is the first bad commit commit f2e5b8070776268912e1886d4516d7ddec6969fc Author: Alexandre Julliard julliard@winehq.org Date: Thu Dec 12 19:19:12 2019 +0100
kernel32: Use the Get/SetComputerName functions from kernelbase.
Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/kernel32/computername.c | 542 ++++-------------------------------------- dlls/kernel32/kernel32.spec | 10 +- dlls/kernel32/tests/environ.c | 11 + 3 files changed, 61 insertions(+), 502 deletions(-)
Reverting this commit from Staging 5.0rc1 makes the issue go away.
https://bugs.winehq.org/show_bug.cgi?id=48293
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Wine Component|-unknown |-unknown Regression SHA1| |f2e5b8070776268912e1886d451 | |6d7ddec6969fc
--- Comment #2 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Still present in 5.0-rc2.
I also tested plain Wine, and results are the same: last working commit is 7822b854110dd1da0471489beab8f6ce04eb418b, commit f2e5b8070776268912e1886d4516d7ddec6969fc introduces the issue.
https://bugs.winehq.org/show_bug.cgi?id=48293
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC|leslie_alistair@hotmail.com | |, z.figura12@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- What's your hostname set to? Probably that fails to resolve in the DNS.
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- Created attachment 66101 --> https://bugs.winehq.org/attachment.cgi?id=66101 Avoid DNS lookups
Does this make any difference?
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #5 from Maciej Stanczew maciej.stanczew+b@gmail.com --- The patch doesn't help. Applied on top of 5.0-rc2 (Staging), the UI still lags.
I am running Arch Linux with systemd-resolved, a statically set one-word hostname (without domain part), empty /etc/hosts, and the following 'hosts' entry in /etc/nsswitch.conf (Arch's default): hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
Hostname lookup using resolvectl completes quite quickly: -- Information acquired via protocol DNS in 796us.
After your suggestion and a bit of digging with '+computername,+reg', it seems that it's the lack of domain part that is causing the issue with new code. If I append ".local" or ".whatever" to my hostname, the issue is gone.
Tomorrow I'll try to gather the logs and test more configurations.
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #6 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 66157 --> https://bugs.winehq.org/attachment.cgi?id=66157 Logs with a one-word hostname (without domain part)
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #7 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 66158 --> https://bugs.winehq.org/attachment.cgi?id=66158 Logs with hostname that includes domain part
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #8 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Attached logs with '-all,+computername,+reg,+timestamp'. I checked two hostname configurations (one with and one without domain) and three Wine configurations (clean 5.0-rc2, rc2 with dns.diff applied, and rc2 with f2e5b807 reverted).
With hostname that includes domain, there is no reproduction on any Wine configuration. With hostname that does not include domain, there is reproduction on clean 5.0-rc2 and the one patched with dns.diff. There is no repro with commit f2e5b807 reverted.
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #9 from Maciej Stanczew maciej.stanczew+b@gmail.com --- And timestamps at which I clicked the UI buttons to switch between games (each time for about 10-12 seconds): - nodomain-commit-reverted: 350 - nodomain-5.0-rc2: 520 - nodomain-dns-patch: 710 - domain-commit-reverted: 200 - domain-5.0-rc2: 340 - domain-dns-patch: 440
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- I guess the empty domain for some reason takes longer to resolve on your machine. You can probably try +winsock or +dnsapi traces to figure out why.
The previous version would return the hostname as domain name if the real domain name was empty, but I don't think we want to continue doing that. It's not what Windows does either.
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #11 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 66188 --> https://bugs.winehq.org/attachment.cgi?id=66188 Logs with +winsock
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #12 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Added logs with '-all,+timestamp,+computername,+winsock,+dnsapi' (although there doesn't seem to be any logs for dnsapi). In both cases I switched games at timestamps 70, 80, 90 and 100.
The only obvious difference I can see is: WS_getaddrinfo "wpad.mydomain", (null) (nil) -> 0x329f0c -2 vs WS_getaddrinfo "wpad.", (null) (nil) -> 0x329f0c -3
And in the case without domain it does indeed appear about a second after the button was clicked (70.265 vs 71.086, 90.156 vs 91.085).
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #13 from Maciej Stanczew maciej.stanczew+b@gmail.com --- It turns out systemd's resolvectl will hang for about 800-900 ms when doing a query for a hostname without domain: $ time resolvectl query 'whatever' whatever: resolve call failed: All attempts to contact name servers or networks failed real 0m0.845s $ time resolvectl query 'whatever.' whatever.: resolve call failed: All attempts to contact name servers or networks failed real 0m0.871s
With added domain the query completes (fails) much quicker (and with a different result): $ time resolvectl query 'whatever.myhost' whatever.myhost: resolve call failed: 'whatever.myhost' not found real 0m0.012s
So what probably happened here is: before f2e5b807 Wine was doing a query for "wpad.myhost" (since domain is empty it used hostname in its place), and the query failed quickly; and after f2e5b807 Wine is not using hostname in case of empty domain, so it queries for "wpad.", which takes much more time in resolvectl.
Question is, where does this "wpad" come from? It's not my hostname, so why is it queried in the form of "wpad.mydomain"?
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Created attachment 66190 --> https://bugs.winehq.org/attachment.cgi?id=66190 Avoid trailing dot
wpad is used for web proxy autodiscovery. Does this make a difference?
https://bugs.winehq.org/show_bug.cgi?id=48293
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #15 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 66191 --> https://bugs.winehq.org/attachment.cgi?id=66191 Log with patch 66190
The patch does help, but I don't know if it's in the expected way (I hope it is, because behavior is much better).
With previous configurations, every time I clicked UI objects there were WS_getaddrinfo requests passed to resolver (for "wpad.myhost" or "wpad."). "wpad.myhost" was sent over DNS, which returned "not found" after about 100 ms, and the result was cached, so subsequent queries were handled in about 10 ms (measured with 'time resolvectl'). "wpad." was sent over LLMNR [1], and since there is no such host on the local network, it timed out -- but not after two retries and waiting 250 ms after each message, totaling in over 750 ms of delay. And the result was not cached, so every request took such a long time.
With this patch there are no WS_getaddrinfo requests *at all* when clicking UI objects. There are requests for "wpad", but they are not at any specific timestamps. I attached log with this patch (and no domain set), switched games again at timestamps 70, 80, 90 and 100; and "wpad" is queried at about 52, 61 and 98.
Looking more carefully at previous logs I can also see that there were requests for "wpad" (without the dot), mixed with the ones with the dot: $ grep -c '"wpad.' *.txt domain.txt:50 nodomain.txt:54 $ grep -c '"wpad"' *.txt domain.txt:7 nodomain.txt:5 And with the patch there are just 5 requests in total (instead of almost 60): $ grep -c wpad *.txt nodomain-trailingdotpatch.txt:5
[1] From systemd-resolved manual: "Single-label names are routed to all local interfaces capable of IP multicasting, using the LLMNR protocol." If I disabled LLMNR the requests were handled much quicker, but then I didn't have local name resolution on my network, which I use.
https://bugs.winehq.org/show_bug.cgi?id=48293
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |b276bda5a21df595973e3ad5552 | |c66a1799f5d3c Resolution|--- |FIXED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- OK, it should be fixed by b276bda5a21df595973e3ad5552c66a1799f5d3c then. Thanks for your help!
https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #17 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Thank you! And just to confirm, behavior before f2e5b807 was the same as after b276bda5: just 5 requests for "wpad" without the dot, at timestamps not related to UI clicks.
https://bugs.winehq.org/show_bug.cgi?id=48293
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.0-rc5.
-
WineHQ Bugzilla