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.