mouse input lag under X11

[benoit-pierre]

When using a high polling rate mouse on Linux with X11, the mouse cursor lags. After investigation, it turns out this is due to the fact that Allegro will only process up-to 5 X11 events at a time, and so mouse motion events will pile up and the mouse cursor will lag (as reported here).

It's also possible to fix this in AGS by setting a custom X11 input handler as seen here: df953ff.

[shmerl]

I noticed the mouse lag as well.

UPDATE: I can confirm that this patch indeed reduces the lag.

[benoit-pierre]

Only reduce? For me the lag is completely gone.

[shmerl]

You are right, it was just a subjective feeling because there were some delays between loading screens, but those aren't related. I tested it, and it again and I don't see lag now with this fix.

[ghost]

I have a question: if Allegro authors had deliberately limited number of events to parse per turn, perhaps they had a reason to do so. Cannot this patch make things worse in some case? Maybe there should be some condition to turn it on?

[shmerl]

Sorry for the off-topic, but do you have a plan to switch to SDL from Allegro? It would be much better in the long term for these kind of issue. Consider also Wayland support.

[benoit-pierre]

@ivan-mogilko : unfortunately looking at the VCS history does not give any clue as to why this was done like this, but event processing is not limited either in the more recent version (e.g. 5.1).

[ghost]

@shmerl

Sorry for the off-topic, but do you have a plan to switch to SDL from Allegro? It would be much better in the long term for these kind of issue. Consider also Wayland support.

This was in consideration since we started to work on this project; we were thinking about SDL, and Allegro 5, but I could never find time to actually do that, because I had a lot of requests about more "high-level" engine features, and most people are working on this project irregularly.
At the moment I am not even sure how much more I will continue working on this, and if I will at all.

@benoit-pierre

but event processing is not limited either in the more recent version (e.g. 5.1).

Okay, it is good to know that.

[ghost]

Implemented this patch as 6a35ec9 (code is generally same, just put into different place).

[ghost]

It was found that adding the patch to AGS (original: df953ff, implemented as: 6a35ec9) actually causes tremendous delays between the game renders, if the game is run in a window size equal to its native resolution (without scaling filter).

Debugging shows that in such case the allegro's input handling routine is being called 20 or more times in a row, hinting that the event queue is very large (or that program logic is broken somewhere).

I tried applying same patch over the master branch to see if this has something to do with the changes made in latest months, but the result was the same.

Since apparently this patch was being used for quite a while already, I would like to clarify, did you use the patch to AGS, or patch to Allegro, and did any of you ever tried to run the game without scaling filter while having this patch on?

[benoit-pierre]

Is that only when moving the mouse cursor? Are you using a high polling rate mouse? If I remember correctly (it has been a while...), I was using a patch with a pre-loaded shared library with a Steam version of an AGS game, and also did play a number of other games with a patched version of Allegro and a custom version of AGS (compiled locally to play some Windows only games). I'm pretty sure I was playing in windowed mode, but I don't remember if I was using a scaling filter or not...

[benoit-pierre]

What would be the content of acsetup.cfg for your use case?

[ghost]

It just happens on its own, I may not touch the mouse at all.

I use a game with animated introduction for a test, and the animation progresses, but game frame is got redrawn only once in 5-8 seconds.
It occurs in both windowed and fullscreen modes, but only if no scaling filter is on. That seem to be the only condition, rest of configuration does not seem to be important. Actually, it may be empty, just running the game as "ags --gfxfilter none" does it.

If I comment out a line which assigns a custom XWin input handler, everything gets back to normal.

[benoit-pierre]

Which game is that? I just tried some games with ags --windowed --gfxfilter None and had no issue (that's with my version of AGS/Allegro). Did you check what type of events you were getting?

[ghost]

I will test with several other games shortly, but I was not the only person who had this issue.

What I wanted to ask, are you sure it is correct to rely on XQLength when repeatedly calling "_xwin_private_input_handler"? May there be types of events in that queue that allegro's input handler does not handle (therefore calling it again may be redundant)?

I will try to print some info from the event queue, but I need to read docs on XWindows first :-).

[ghost]

Update: yes I can confirm that this happens with other games too.

[benoit-pierre]

I would try with a patched Allegro first, as this is were the fix really belongs.

[ghost]

I guess I may have made a mistake by putting this patch into AGS itself.

[benoit-pierre]

OK, so after updating AGS to 3.3.5.2, I can reproduce the problem. Without the _xwin_private_input_handler patch in AGS, and with the patch in Allegro, I don't get any slowdown.

[benoit-pierre]

And the mouse is working fine too, without the patch in Allegro, the cursor lag is back.

[ghost]

It looks like this is another bug that would be fixed by switching from Allegro to SDL2.
(Sorry for the pro-SDL2 spam, I’ll stop here for today ;).)

[ghost]

There was no need for "pro-SDL2" spam. Simply making one single issue would be more than enough.

Moving to SDL2 has been in plans for a while, and doing so requires quite a bit of work. @sonneveld is trying to make this change currently in their personal fork, in steps, but that may take a while to get everything set up.

[shmerl]

SDL1 is not supported upstream and is already deprecated. It never should be used for anything new for sure. It doesn't work with Wayland and is basically EOL already. Something old using it is not the reason for anything new to continue using it. They are not very similar, and it's not easy to switch, as various projects which struggle with it can attest (ScummVM for example).

Besides, SDL1 has the same issue like the bug #202, i.e. Alt+Tab doesn't work with it properly, unless developers work around it explicitly. It's very annoying in a lot of older games, and surely should not be followed.

[morganwillcock]

Just to confirm, this issue does seem to appear based on the input device. Playing a very high resolution game (so no scaling is in effect) with a mouse that has a switchable tracking speed seems to result in very sluggish and delayed movement, not changing anything else and using a trackball with switchable tracking speed (I've got both plugged in at once), I have no problems with input performance. I guess the mouse just generates more events.

[morganwillcock]

I don't think that events are being discarded, just there are just too many to process in real-time. The path for cursor motion is 'correct', but does not keep up with the physical motion of the mouse. I guess if it is possible to track the rate of events and differentiate between movement and a click, you could only accept a limited number of movement events (per tick?) into the event queue, but keep all click events.

[vga-256]

I've read through this thread a couple of times, and I don't quite follow if/how this problem was addressed in the end? We had a couple of testers report the same sluggish mousing problem on their high-polling-rate mice, and now need to address the bug with a patch.

I've applied the Allegro mouse patch referenced here and manually compiled Allegro 4.4.2. I am hesitant to release the patched Allegro to our users if there is a known problem with the fix.

Furthermore, is there a process for working/including Allegro patches into the AGS source distribution? I rely upon the /ags/debian/make_ags+libraries.sh script, and it does not (from what I can see) make a provision for manually patching Allegro and compiling the libraries.

Thanks for your patience with dealing with all these old bugs I seem to be running into :)

[morganwillcock]

As far as I know it is still an issue, depending on the type of device that is being used. It'll work fine if a mouse with a high polling rate is connected, but not if that is the mouse you are generating input with (i.e. a second mouse on the same system might have no issues).

Asesprite on Linux is building Allegro with X_MAX_EVENTS defined as 50 instead of 5, and with cursor speed functions removed (this might be unrelated), but I think the general consensus was that getting off Allegro 4 is the only way to have it work for everyone. I don't know what state the SDL2 port is in, or even if it is actively worked on, but it might be worth testing the game against that as a potential solution.

I've applied the Allegro mouse patch referenced here and manually compiled Allegro 4.4.2. I am hesitant to release the patched Allegro to our users if there is a known problem with the fix.

The change that was previously made was meant to be functionally equivalent to this patch, but seemed to have negative effect for most people who tried it. It was reverted here.

Furthermore, is there a process for working/including Allegro patches into the AGS source distribution?

I believe the fork of Allegro was originally for Windows specific changes, and other ports dealt with the patches separately, so there would be no mechanism for patching per platform. The Linux build script just expects that you already have all of the pre-requisites.

[SiegeLord]

Sure, please send a PR for anything you want upstreamed. It doesn't appear that X_MAX_EVENTS change has been.

[vga-256]

@rofl0r Ah, no - I just applied that patch because it was the first one I came across to deal with the problem.

[shmerl]

This affects Mage's Initiation. The mouse is very laggy (GOG release).

[shmerl]

I'll try building ags with that allegro events patch to see if it helps.

[shmerl]

@256colour: are you the developer of Mage's Initiation? Can you please update the GOG release with the Allegro's mouse lag fix? See here.

[ivan-mogilko]

We have a SDL2-based version now, this problem has to be retested in it.

[ericoporto]

Playing a very high resolution game (so no scaling is in effect) with a mouse that has a switchable tracking speed seems to result in very sluggish and delayed movement

@morganwillcock do you still have that mouse?

[morganwillcock]

do you still have that mouse?

I do! If you point me in the direction of what to test I can check something.

[ericoporto]

@morganwillcock I don't have the issue unfortunately, but what I was thinking is if you could reproduce the issue you commented years ago here: #162 (comment)

[morganwillcock]

I tried the master branch, building it with CMake, and I couldn't get any lag with any device. So presumably on SDL2 this is not an issue.

[ericoporto]

Thanks! Did the lag appeared when using the non-SDL2 version of the engine?

[morganwillcock]

I cannot, but the Allegro4 version that comes with Debian is now 4.4.3 and this has the same changes to the event limits that the version in the AGS repository has.

[ivan-mogilko]

I think it's safe to close this then. In any case if something is wrong in 3.6.0 it should be opened as a new issue, related to SDL2.