[Bug 49423] Added input lag in World of Warcraft and other games

WineHQ Bugzilla wine-bugs at winehq.org
Tue Jun 23 11:08:45 CDT 2020


https://bugs.winehq.org/show_bug.cgi?id=49423

--- Comment #10 from Zebediah Figura <z.figura12 at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list