https://bugs.winehq.org/show_bug.cgi?id=49423
Bug ID: 49423 Summary: Added input lag in World of Warcraft and other games Product: Wine Version: 4.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: bloodyiron@lanified.com Distribution: ---
In World of Warcraft you use WASDQE to move your character in the world in a very highly responsive manner. When using WINE 4.16, there is no perceptible input lag. However, switching to WINE 4.17 or higher (verified in 5.7 also), there is immediately perceptible input lag. Namely, in a combination of dropped/missed inputs and delayed response to inputs the game receives.
This seems to be reproducible 100% of the time based on my experience and generally everyone else I've asked, or read comments on the topic.
This input lag is so bad it means World of Warcraft should not be played on any version higher than WINE 4.16 until this input lag bug is fixed, as it makes gameplay elements (complex boss fights) nearly impossible.
https://bugs.winehq.org/show_bug.cgi?id=49423
zepar stefanfunk1998@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefanfunk1998@gmail.com
--- Comment #1 from zepar stefanfunk1998@gmail.com --- can confirm that key inputs dont work right for me, and my mouse is not getting captured in fullscreen mode in Final Fantasy XIV with any wine version above 4.16
https://bugs.winehq.org/show_bug.cgi?id=49423
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- Performing a regression test will help this bug be solved quickly. See https://wiki.winehq.org/Regression_Testing for instructions.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #3 from Bloody Iron bloodyiron@lanified.com --- (In reply to Zebediah Figura from comment #2)
Performing a regression test will help this bug be solved quickly. See https://wiki.winehq.org/Regression_Testing for instructions.
How does testing with WINE 5.7 not constitute a rough regression test? I tested with WINE 5.7 today and confirmed the issue.
I myself am really not in a position to compile WINE from source and test very deeply for this.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Bloody Iron from comment #3)
How does testing with WINE 5.7 not constitute a rough regression test? I tested with WINE 5.7 today and confirmed the issue.
By "regression test" we refer to a bisect, to determine exactly which commit causes this bug.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #5 from Bloody Iron bloodyiron@lanified.com --- (In reply to Zebediah Figura from comment #4)
(In reply to Bloody Iron from comment #3)
How does testing with WINE 5.7 not constitute a rough regression test? I tested with WINE 5.7 today and confirmed the issue.
By "regression test" we refer to a bisect, to determine exactly which commit causes this bug.
Ahh okay, well hopefully someone more versed in this process can assist with this. I'm still ultra green when it comes to compiling WINE from source, and getting all the other manual steps in-order. I could eventually figure it out, but I'm afraid that's not in the cards right now.
Considering how consistent the issue is, I suspect this impacts a lot of people. Maybe it'll get some attention soon from someone who can handle this :D
https://bugs.winehq.org/show_bug.cgi?id=49423
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=49423
Anya animegirl@stronzi.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |animegirl@stronzi.org
https://bugs.winehq.org/show_bug.cgi?id=49423
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #6 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #4)
(In reply to Bloody Iron from comment #3)
How does testing with WINE 5.7 not constitute a rough regression test? I tested with WINE 5.7 today and confirmed the issue.
By "regression test" we refer to a bisect, to determine exactly which commit causes this bug.
It is somewhat impossible to do regression testing between releases for "normal people". Especially when talking about difference from 4.16 -> 5.7 if that is the case.
Is there a different way to log what might be causing "input lag"?
Lets pretend that a user just complains about perceived input lag coming from Windows without ever having used prior wine versions... How would one try to figure out what was happening instead of bisecting possible thousands of commits.
https://bugs.winehq.org/show_bug.cgi?id=49423
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #7 from joaopa jeremielapuree@yahoo.fr --- Regression test is fast.
From wine-4.16 to wine-5.7 there is about 7000 commits. That means about 14
compilations are requested to do a regression test.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #8 from Sveinar Søpler cybermax@dexter.no --- (In reply to Bloody Iron from comment #0)
This seems to be reproducible 100% of the time based on my experience and generally everyone else I've asked, or read comments on the topic.
This input lag is so bad it means World of Warcraft should not be played on any version higher than WINE 4.16 until this input lag bug is fixed, as it makes gameplay elements (complex boss fights) nearly impossible.
I cannot really say if i am having the same problem, but since i am an old git, my ADHD reaction time is hugely diminished vs. a 20 year old :) So, this might mean i have an easier time with this...
However, there IS a wee bit of strange latency that i do not like. I cannot put the finger on when this happened, but it might just be around those times (4.16?), and especially i think it has become a wee bit "weirder" after you HAVE to use "capture mouse" option in winecfg to even be able to turn using the mouse (several bugs on this, but it is a feature me thinks). This again, might be related to various "rawinput" patches especially from staging. I think you should use a wine version that have all the needed vulkan extensions enabled to get the most performance out of DXVK, and i kinda think that 4.16 is too old, but will look into this.
Another thing to test to see if it is better/worse is to tweak with wow's input latency settings: /dump GetCVar("SpellQueueWindow") Default is 400 and is mostly way too high unless you have really bad ping. General rule of thumb seems to be ping + 100.. eg with 50ms ping: /console SpellQueueWindow 150 or disable with: /console SpellQueueWindow 0
As i said, i cannot really put a pointy finger at "huge issues" with this when running with wine-5.7->5.9 or Proton, but i play a melee and mostly just disable SpellQueueWindow completely.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #9 from Bloody Iron bloodyiron@lanified.com --- (In reply to joaopa from comment #7)
Regression test is fast. From wine-4.16 to wine-5.7 there is about 7000 commits. That means about 14 compilations are requested to do a regression test.
While my two original samples are between 4.16 and 5.7, the issue is also observed in much earlier versions, namely, 4.17 and 4.20. I personally have seen it in 4.20, and other people I have talked to reported the issue observed in 4.17. So we can limit the range there.
As for age, you don't need to be 20 to observe this issue. I'm much older than that, and ca observe it.
I agree that better methods need to be developed to adapt to the growing Linux userbase. Either way, this is a very easily reproducible issue.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sveinar Søpler from comment #6)
(In reply to Zebediah Figura from comment #4)
(In reply to Bloody Iron from comment #3)
How does testing with WINE 5.7 not constitute a rough regression test? I tested with WINE 5.7 today and confirmed the issue.
By "regression test" we refer to a bisect, to determine exactly which commit causes this bug.
It is somewhat impossible to do regression testing between releases for "normal people". Especially when talking about difference from 4.16 -> 5.7 if that is the case.
Can you please expand on exactly how?
Note that because of the nature of regression testing, as joaopa mentioned, doubling the number of commits means only one extra compilation and run.
Certainly regression testing is time-consuming, and learning to build Wine is also time-consuming. I don't particularly *like* demanding that people do it, but it's an order of magnitude difference for developers.
Is there a different way to log what might be causing "input lag"?
Lets pretend that a user just complains about perceived input lag coming from Windows without ever having used prior wine versions... How would one try to figure out what was happening instead of bisecting possible thousands of commits.
It's significantly harder, and I'm not even sure where I would start. My best guess for a productive avenue is that I'd have to first figure out what's a symptom that's even reproducible in logs (real time difference between successive MotionNotify events? real time difference between GetCursorPos or similar calls? I'm not even sure either would be a reliable indicator), and then slowly work through the code to figure out what's causing that difference. Since of course I don't have the game, I'd probably have to ask the reporter for many logs, and eventually I may run into either (1) a potential solution or (2) a need for logging that Wine code doesn't already have, meaning that the reporter will need to compile Wine *anyway*.
By contrast, a bisect will usually point exactly where the problem is. In terms of developer time, it takes quite a lot less.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #11 from Sveinar Søpler cybermax@dexter.no --- (In reply to Zebediah Figura from comment #10)
Can you please expand on exactly how?
Note that because of the nature of regression testing, as joaopa mentioned, doubling the number of commits means only one extra compilation and run.
Certainly regression testing is time-consuming, and learning to build Wine is also time-consuming. I don't particularly *like* demanding that people do it, but it's an order of magnitude difference for developers.
Well, since this is staging, it is not ONLY wine commits that has to be bisected. Lets say it is 200 commits between wine-deve-4.16 -> 4.17 (to narrow it down). I know 4.16 = "good", and 4.17 = "Bad". My first bisect would then be 4.16+100 (half right?).
Thats fine, exept i might not be able to apply staging at that point. Staging does not get rebased on a "per commit" basis in case of breakage, but sometimes quite a few commits later. So lets say the rebased "staging" is then 4.16+132. Fine, that is also "bad". Next bisec would then be 4.16+66. Lets say once again i am unable to apply staging, but have to apply to eg. 4.16+49. This is "good". Oki.. then i might end up unable to apply staging AT ALL on any of the commits between 4.16+49 -> 4.16+132
I cant see me applying staging to 4.16 and the merging 4.16+100 either, as that is 99% sure to fail, not to mention having to keep tabs on what patchsets gets added/removed/disabled/enabled inbetween those commits.
I know it might not be exactly like this, but i have done tries before, and have ended up with a commit range not likely to be accurate enough for any devs to bother.
Sorry if i have missunderstood the whole consept tho, but bisecting "staging" when you do not know if it is a staging patch or a wine commit that is the culprit is a bit over medium hard for "regular folks" imo.
I know it might be that wine-4.16 only needs 2-3 patchsets to work with Battle.net/WoW, but i do not know the minimal patchset needed. I am willing to try if someone know the absolute minimum patchset tho, so it is way less to fiddle with. (Verified one at that, not "it should probably possible work with only X and Y")
By contrast, a bisect will usually point exactly where the problem is. In terms of developer time, it takes quite a lot less.
I do understand... no problem. It is just not that easy ref. my attempt to describe the problem above.
Another thing to worsen this problem is that WoW is NOT playable with WineD3D AT ALL (nope.. having 4-5 fps is NOT playable). So you would need DXVK to get this working, and recent DXVK might need recent wine and/or vulkan patches to work properly too.
Sorry, i do understand your problem, but hopefully you also understand mine :) That is why i asked if there was something that could be logged. Maybe a overly amount of "key-press-buffer-overrun" or whatever that MAY point in a certain direction :)
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #12 from Sveinar Søpler cybermax@dexter.no --- (In reply to Bloody Iron from comment #9)
As for age, you don't need to be 20 to observe this issue. I'm much older than that, and ca observe it.
I agree that better methods need to be developed to adapt to the growing Linux userbase. Either way, this is a very easily reproducible issue.
I have been testing with wine-staging-4.16, and dxvk-1.4.6, and initial testing, kinda feels a wee bit "snappier". I almost thought my mouse settings had changed. (I actually recreated the prefix, as there was some huge breakage with old/new prefixes a while back, so to make sure prefix was not semi-borked by something i recreated it)
Now, the difference is not THAT huge (for me), and there is massive problems with zones experiencing serverlag these days, so its hard to quantify. Running a couple of Visions atleast seemed a bit smoother. I would not go as far as saying using eg. 5.7 is "unplayable" in comparison, cos for me the difference is not that huge.
I know there was done quite a bit of work on the "rawinput" side of patches around those times (4.16+), and i have seen some reverts on the TKG repo (that Lutris builds from). This supposedly was fixed a bit later, but looking at the staging patches from 4.16 -> 4.17 and beyond, the "rawinput" patches have grown in size. I do not have an estimate of how much of this is upstream either, but i somehow have a slight suspicion in that direction.
I will do some more testing with 4.16 as i dont see any problems using that for my WoW prefix currently.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #13 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with plain wine-7.0-rc5?
https://bugs.winehq.org/show_bug.cgi?id=49423
Marco Kretz mk@marco-kretz.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mk@marco-kretz.de
--- Comment #14 from Marco Kretz mk@marco-kretz.de --- Bug still persists in current wine-7.4 as well as 7.5.r2-tkg (default patchset). As it seems to be DE-agnostic: I'm running GNOME 41.3 and have this issue on X and Wayland.
It is easy to reproduce. Just move fast with WASD, jump a little and soon you'll get a dead input.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #15 from Sveinar Søpler cybermax@dexter.no --- (In reply to Marco Kretz from comment #14)
Bug still persists in current wine-7.4 as well as 7.5.r2-tkg (default patchset). As it seems to be DE-agnostic: I'm running GNOME 41.3 and have this issue on X and Wayland.
It is easy to reproduce. Just move fast with WASD, jump a little and soon you'll get a dead input.
It might not be that big a difference between X vs XWayland, as i don't think wine is Wayland compatible yet, and would need XWayland to work. It might not be THAT DE-agnostic then.
Have you experimented with winecfg and "Capture mouse" option, aswell as "Virtual Desktop" settings to see if it makes any difference? A completely dead input should be possible to log, but "general latency" is a bit harder.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #16 from Marco Kretz mk@marco-kretz.de --- After some testing it seems to not occur anymore when enabling "Capture mouse in fullscreen applications" in winecfg. I'll do a raid this evening and report back if it still happens in heavy movement scenarios.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #17 from Marco Kretz mk@marco-kretz.de --- 3 hours of raiding and not a single dead input. So yes, "Capture mouse in fullscreen applications" within winecfg works! I would be really interested in why? Is there an explaination?
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #18 from Sveinar Søpler cybermax@dexter.no --- (In reply to Marco Kretz from comment #17)
3 hours of raiding and not a single dead input. So yes, "Capture mouse in fullscreen applications" within winecfg works! I would be really interested in why? Is there an explaination?
Not sure.
https://bugs.winehq.org/show_bug.cgi?id=47764 https://bugs.winehq.org/show_bug.cgi?id=48322
A couple of other bugs regarding the same - sometimes "fixed" and other times not.. could be different reports with/without this "capture mouse in fullscreen applications".
Don't have a answer i am afraid.
https://bugs.winehq.org/show_bug.cgi?id=49423
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- Does this still occur in Wine 9.8 or later?
https://bugs.winehq.org/show_bug.cgi?id=49423
soredake broaden_acid002@simplelogin.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |
-
WineHQ Bugzilla