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.
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.