alacritty: High CPU load when moving window between monitors

I can also confirm that my issue originates from moving alacritty between monitors.

https://github.com/tomaka/winit/issues/706 is now fixed 👌

The fix shipped in 0.2.6. https://github.com/jwilm/alacritty/commit/5d3cbe51bc05226467e648f88e46012ca94316d4

I opened a PR fixing this on winit.

The temporary fix by @15cm works, since the problem is caused by winit attempting to preserve the DPI-adjusted window size when moving across monitors. Making Alacritty float allows the resize to the desired size pass, stopping winit from continuosly attempting to resize the window.

Inspired by @dzmien, I find a temporary workaround to be toggle floating twice of all Alacritty instances every time we move Alacritty between monitors, using script like this:

for i in $(seq 2); do
  i3-msg '[class="Alacritty"] floating toggle'
done

I am having the same problem: Which operating system does the issue occur on? 4.19.2-arch1-1-ARCH

If on linux, are you using X11 or Wayland? X11, i3, xcompmgr

Running alacritty 0.2.3 from official Arch package. Moving alacritty between screens causes xorg’s CPU usage to spike and plateau there until alacritty is closed. Restarting i3 in place does not fix the problem. Manipulating the alacritty window in any other way as long as it stays on the same monitor does not cause any problems. Interestingly, I can float the alacritty window and drag it to the other monitor and then push it back into tiling without issue.

Here is alacritty -vvv output starting from the command to move Alacritty to the other monitor (ends when I exit alacritty)

[11:00:25] Term::resize [11:00:25] num_cols, num_lines = 118, 63 [11:00:25] width: 954, height: 1020 [11:00:25] carriage_return [11:00:25] carriage_return [11:00:25] move_up: 1 [11:00:25] goto: line=0, col=0 [11:00:25] Set Attribute: Reset [11:00:25] Set Attribute: CancelReverse [11:00:25] Set Attribute: CancelUnderline [11:00:25] clear_screen: Below [11:00:25] Set Attribute: Bold [11:00:25] Set Attribute: Foreground(Named(Green)) [11:00:25] Set Attribute: Foreground(Named(Blue)) [11:00:25] Set Attribute: Reset [11:00:25] Set Attribute: Foreground(Named(White)) [11:00:25] Set Attribute: Reset [11:00:25] carriage_return [11:00:25] linefeed [11:00:25] Set Attribute: Foreground(Named(Blue)) [11:00:25] Set Attribute: Bold [11:00:25] Set Attribute: Foreground(Named(Blue)) [11:00:25] Set Attribute: Reset [11:00:25] Font size changed: Size(24) [DPR: 1] [11:00:25] Term::resize [11:00:25] Term::resize dimensions unchanged [11:00:25] width: 954, height: 1020 [11:00:39] backspace [11:00:41] unset_mode: CursorKeys [11:00:41] unset mode::TermMode::APP_KEYPAD [11:00:41] unset_mode: BracketedPaste [11:00:41] carriage_return [11:00:41] carriage_return [11:00:41] linefeed [11:00:41] Goodbye.

https://pastebin.com/9fY449ez <-- there is the entire alacritty -vvv output.

I have the same issue using arch, i3, alacritty-git from AUR (updated a few seconds ago) 0.2.3.

Moving alacritty to another display will make xorg, i3 and alacritty to use 100% cpu. I have scaled one of the display as it is high dpi. I didn’t have this problem a few days ago.

Anything i could provide to make the debug easier?

Edit: Restarting alacritty will lower the usage to normal again.

I didn’t upgrade yet, and I haven’t reproduced it yet. But I’ll upgrade now and report back in a few days

Just if someone sits on archlinux and has the same problem, installing the AIUR community package alacritty-git fixes the problem. So seems like it is the package in the official repository that has a problem.

Maybe this issue could be resolved by just updating that package, of course it is interesting to find out what caused it though 😃

I’ll enable full logging when that is merged. For now it seems to happen rarely and I don’t want to start all my terminals from other terminals just to get the output.