alacritty: Redraw randomly hangs until a keypress
Using Alacritty (commit 6916537858d12e02478d618339d1b9f0e73a677a) on Ubuntu 16.04 with X11.
It is better described with the following screencast. Here I’m repeatedly opening and closing tig
, so the output should be the same in each iteration. The screen often stays in a partially redrawed state (marked by mouse cursor movement). Then it finishes redraw correctly when I’m pressing a key.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 27
- Comments: 81 (19 by maintainers)
Commits related to this issue
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Update to winit/glutin EventLoop 2.0 This takes the latest glutin master to port Alacritty to the EventLoop 2.0 rework. This changes a big part of the event loop handling by pushing the event loop i... — committed to chrisduerr/alacritty by chrisduerr 5 years ago
- Use termite until alacritty redraw fix https://github.com/jwilm/alacritty/issues/824 — committed to ratorx/dotfiles by deleted user 5 years ago
- Use timer based rendering instead of vsync Given that alacritty handles all the windows on the main thread using vsync will result in sequential locks on swap buffers for each window it'll try to dra... — committed to kchibisov/alacritty by kchibisov 2 years ago
Note that (as of today) an arch package
alacritty-git
is out of date (v 0.3.3). This version still suffers from this issue. What’s more (as it has been already said) 729eef0 solved an issue. So it should be closedI immediately updated now that I saw #2438 was merged. This seems to have solved all of the issues I had relating to this (and so much more) 😍
It’s happening on my i3-gaps + compton machine too. It seems that switching compton backend from
glx
toxrender
helps.This is still happening for my on 0.12.2 on pop-os 22.04 as well.
Still happens to me with 0.12.2 , on pop-os (based on Ubuntu) 22.04 LTS. I haven’t seen it except with tmux as the shell, though I haven’t tried very hard. With tmux, every couple of minutes 😦
@kchibisov, I’m running X11 with tmux and experience the issue mentioned here and in https://github.com/alacritty/alacritty/issues/4362. Have not experienced the issue since switching over to https://github.com/alacritty/alacritty/pull/6175 (been running it for ~3 days)
@Dzordzu the package is not outdated. In fact, there’s no package, there is a PKGBUILD (package build script). The PKGBUILD will fetch and build the last commit. There’s nothing outdated.
I’ve tested https://github.com/jwilm/alacritty/commit/729eef0c933831bccfeac6a355bdb410787fbe5f as well, seems like the issue was solved in it’s entirety, no bell issues too.
Thanks for the amazing support!!! 💯
As of 729eef0c, on my system (Arch Linux, X11, awesome WM ), a visual bell stays “on” until some interaction with the window is performed (such as moving the mouse):
$ sleep 1; echo '\a'
I think I can reproduce this issue with the evlp2 branch. So this needs more investigation.
I’m looking forward to glutin eventloop 2.0 which is actively worked on and will eventually fix the issue. But until then it drives me nuts. It happens a lot and I constantly press random keys, because I’m afraid the terminal isn’t updating.
Is there a workaround to avoid having to switch to a different terminal emulator? E.g firing events constantly, disable optimization or to use an older version of alacritty or https://github.com/chrisduerr/alacritty/commit/1e8e9046cec57b7f08748cacbbed17ae9170ae66?
Happens to me too. Usually I blamed ssh connection for that, but today it happened twice when running something locally. I don’t use tmux or any other terminal multiplexer.
Happens much more frequently on my laptop, where I have ubuntu 14.04.6 LTS with Alacritty v0.2.9, but also happens at my workstation/desktop, where I run arch linux and have 0.3.3-2 installed.
Always happens when long (but not extremely long) output happening and scrolling the screen (like building something or
pacman -Syyuu
), but maybe it’s just because I happen not to press keys while it’s happening. (when I type, maybe it would happen too, but it’s easy to be unnoticed).UPD: This indeed seems to be i3 specific, I also run i3wm. On the laptop where it happens the most, I believe I don’t use any composition manager.
That’s completely irrelevant whether they worked or not. The issue is that one frame on X11 is not being presented to the display for whatever reason when we draw and submit it, so for now the only viable solution would be to draw e.g. 3 times last redraw just to ensure that the frame goes to display.
X11 is just not great when it comes to hardware acceleration, because it was never designed with it in mind, so things break like that is not surprising. Keep in mind that contiguous redraw generally works, because it’s contiguous. For now only nvidia and llvmpipe seems to be broken, and intel using legacy xf86-video-intel(shouldn’t be used anyway).
We’re aware of issue with nvidia/llvmpipe on X11, which is likely not our issue, but just how x11 works. there’s #7251.
It seems like the maintainers aren’t looking at this thread, it might be time to create a new issue and just link to this one.
I just found something that might actually help to uncover the underlying issue here. Hear me out, its a bit of a long story:
I have an i7-1065G7 CPU with Iris graphics inside a Dell XPS 13 7390 2-in-1.
I had a bunch of problems with anything that uses gpu acceleration over the last couple of weeks but a combination of:
… prevented me from resolving it.
However, this weekend I switched to GNOME because I just go too frustrated with certain problems (not related to this one) in KDE Plasma.
GNOME resolved my PLASMA-Problems but introduced two others:
As described in my arch linux forum post: After two painfull afternoons of googling and poking around it turned out that gnome-shell fell back onto rendering on the CPU using
llvmpipe
becausemesa
was loading the wrong driver for my GPU!I discovered this by checking
journalctl -b /us/bin/gnome-shell
and seeing warnings like these:MESA even attempting to load
i965
is odd, since my GPU needs theiris
driver! Noti965
! So I decided to take a proper look at this, ended up setting:MESA_LOADER_DRIVER_OVERRIDE=iris
in my/etc/environment
and BOOM:AND:
And this might also be the reason while it randomly affects certain people but is unreproducible for the maintainers of alacritty. MESA loading the wrong GPU driver can go unnoticed for a loooong time (in my case: weeks) since most applications will just fall back to tormenting your CPU. My Plasma was probably running on the CPU for weeks without me noticing!
I just tried forcing it both ways and it doesn’t make a difference.
See #5883. Our issue is different from this one since it’s severe lag as opposed to indefinite hanging.
I think you should report a separate issue. FYI I am running on macOS 12.1 with no issues. I only saw this issue on linux and what you describe doesn’t sound like the same thing (waiting for output doesn’t help). Also the fact that you have problems with firefox as well, could mean that your issue is not related to alacritty at all.
My bad. The problem with package versioning on my machine (that lasted for almost a half a year from now) was on my side. I’m sorry for interrupting.
This is great stuff! I would greatly appreciate a new release with this fix in it as I can finally recommend Alacritty for colleagues and projects!
It would be possible to use an older version of Alacritty until the issue is resolved.
There are also some patches in the archlinux repository which downgrade the glutin version, applying those might solve the issue though their focus seems to be on resolving transparency problems.
I would also expect the evenloop 2.0 pull request to be usable soon on Linux. My plan is to resolve the remaining issues in Alacritty within this week, however that does not mean that there won’t be any remaining issues upstream. However on macOS this won’t help at all.
So those are the main options for now. The next Alacritty will definitely release with this fixed, hopefully relatively soon once the upstream macOS issues are resolved.
The issue you’re looking for is https://github.com/jwilm/alacritty/issues/2217. Please don’t spam either of them with +1’s, since that will likely just burry useful information. If there’s additional information required, I’ll let you know, thanks.
I can also confirm that it happens during streaming console output (
cat filename
orgit pull
ormake
to build something), it’s not specific to being full-screen (like vim or tmux) or running multithread in some way.@gbalke you’re observing this one #2217 .
Also seem to have this issue (I think anyways) I noticed long stretches of code like building a fork of aosp for Android or just playing music with mpd + ncmpcpp the terminal & visualizer will appear to hang but keyboard input or mouse movement will have it immediately redraw and catch up. This is on Arch Linux with Nvidia’s vulkan beta drivers 418.52.14 on xorg-server 1.20.5-1.
Hi @chrisduerr I tried #1518 with #1403 and I’m still seeing the issue (randomly). No idea what’s going on (is it related to the GPU?). This turns Alacritty a bit unusable 😦 (the only apparent way to force a redraw in my case by opening a new window and send the current (hanged) alacritty window to the back).
@dominik-zeglen the compton change fixes the issue for you?
This issue just started happening to me for the first time. I’ve been using alacritty as my main terminal for about 6 months and haven’t seen the problem before, until now.
I was able to narrow down the context in which the problem happen, at least for me. It only happens when using a compositor (happens with both mutter/gnome and compton for me), and when there are multiple Alacritty windows open. It does not happen with composition and just one window.
PS: Deleted my previous messages since they weren’t really accurate