[1.3.3117+R+I] Dragging mouse while things are selected causes stuttering/freeze

[GinjaNinja32]

Seems to be specific to the Linux build of the game; this does not occur in Windows or when running the Windows build on Linux using Proton. All three situations were tested on the same hardware.



Selecting things and then interacting with the game by dragging the mouse (middle-click drag the map to pan, left-click drag the map to select, left-click drag stockpile sliders and wiggle the mouse quickly, etc) causes significant stuttering and freezes. This is worst when panning the map - selecting a single grow zone and panning the map is noticeably stuttery; selecting multiple and panning causes long freezes (the longest I have a specific number for was 60.7 seconds; I have definitely experienced multi-minute freezes in the past, and I suspect they were caused by this issue). Panning the map using the arrow keys does not display the issue edit: only shows the issue with grow zones selected, not with rock chunks???.

Happens in all saves, at all times, both modded and vanilla.

The easiest way to reproduce this issue is to start a new colony, zoom out and double-click a rock chunk to select 100-200 of them, then drag a new selection box or pan the map with the mouse.

Pretty sure the logs don't have anything useful, but here's a log where I started the game, started a new colony, then triggered the issue



Possibly related, but may be separate: relatively slow mouse movements seem to be ignored by the game - if I e.g. drag a selection box or UI slider quickly, then slow down and move the mouse slowly, I can get the mouse to move without changing the selection box or slider. This situation only resolves itself when I move the mouse quickly or release the left button.
If I do this with a selection box while grow zones are selected, any mouse movement that doesn't cause visible changes to the selection box doesn't trigger the stutter/freeze.
(This slow-mouse-movement issue is also Linux-build specific; it does not happen in the Windows build, either on Windows or using Proton)

[Pheanox]

Thanks for the bug report, we apologize for the inconvenience of this issue. I've added this to our bugs that seem to be coming from linux with the new update.

[GinjaNinja32]

I've now managed to reproduce this on the Windows build, both with Proton and in Windows itself, and I've also managed to have someone else reproduce it on their machine (also Windows) by following the same steps (included below).

The issue is significantly less pronounced in the environments where the Windows build runs, requiring 100+ grow zones to trigger.


Reproduction steps:

1. On a new or existing colony, build this arrangement of grow zones:
https://cdn.discordapp.com/attachments/256853479698464768/904471596343894026/unknown.png
(The outer box is 15x31; there are 106 grow zones in total)

2. Select all the grow zones.

3. Hold [A] and [D] simultaneously. There is a probabilistic element here; if it doesn't trigger after 5-10 seconds, release both keys and retry. If it repeatedly fails to trigger, try with more grow zones - under Proton it required ~150 zones, but under Windows it only took ~100. These numbers may vary by machine.


Other observations and theories:

I think the input rate is capped much lower on Windows and under Proton than it is with the native Linux runtime. Holding A+D or dragging a selection box with _nothing_ currently selected, under Windows the framerate display in Dubs Performance Analyser shows 120-130, but under Linux it shows ~90 with the keyboard or ~1060 with the mouse; this is all on a 60Hz monitor with a 1000Hz polling rate mouse.

I suspect that this high input rate on Linux is the reason I was initially unable to reproduce this on Windows - the threshold for actually triggering it is significantly lower there, and it seems that there is both a probabilistic element to it and a behavioural change at a certain point.
Under Windows, selecting ~75 grow zones (or ~135 on Proton) and holding A+D generally caused high but bounded lag, with update times rapidly reaching ~500ms but not growing much beyond that. Occasionally it would instead cause exponentially (or at least apparently so) increasing lag.
Selecting ~100 grow zones (~150 on Proton) shifted the probabilities so that the increasing-lag case was more likely, though it was still possible to get the bounded case.
Under Linux, the threshold for the exponential case with the mouse appears to be far enough below 1 grow zone that it essentially always triggers when a grow zone is selected, and is low enough to observe with rock chunks instead of grow zones. With the keyboard, the threshold where the increasing-lag case becomes more likely appears to be somewhere in the region of 40-45 grow zones.

[Jump]

1. Running Zorin OS 16 and playing the game through steam.

2. When the mouse is moved slowly over a menu it is evident the game isn't registering the location of the mouse because the buttons aren't lighting up as they should. The mouse seems top be smooth while moving fast so in order to see tool tips I need to move my mouse away and quickly back to the icon I want to hover over. This issue is also present when using the middle mouse button to navigate the map. when I move my mouse slowly it will update very rarely and when I move fast there is no issue.
This problem isn't present if I force it to run the windows version using proton.
I found others with the same issue but on other Linux distros here: https://www.reddit.com/r/RimWorld/comments/ovcarv/mouse_pointer_not_accurate_moving_mouse_slowly/
I recorded the issue: https://youtu.be/Kg99CCOpWjE

3. Smooth movement of the map while using middle mouse button and moving the mouse slowly, tool tips always showing up no matter how slow I moved my mouse.

4. Use Zorin OS 16, start game using steam, move mouse slowly down the menu options to see if they light up.

Thanks for reading my post and I hope this gets fixed soon.

[tuk0z]

Yeah there's been quite some reports on this. Many were suppressed (hopefully merged) but here's one alive, where gycklarn posted a nice animated screenshot that describes part of the issue quite well: 
https://ludeon.com/forums/index.php?topic=54419.0

[Pheanox]

Thanks for the detailed research and reproduction on a windows PC.  I have added this on to the report I have in with the devs and let them know it is now a cross platform issue.

[weekendwarrior]

I can confirm this problem on Arch linux as well. Sometimes it's enough to select just one pawn.