Alacritty blinks on resize

[andreyorst]

OS: Arch Linux, openSUSE
DE: KDE
Compositor: KWin
Display Server: Xorg

Resizing Alacritty causes weird flickering
check this video:
(epilepsy warning)
example.zip

[NickeZ]

Here is also a movie of another blinking behavior. Seems like alacritty fails to redraw content fast enough during resizing. gnome-terminal looks good.

out.ogv.gz

 glxinfo  | grep OpenGL
60:OpenGL vendor string: Intel Open Source Technology Center
61:OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
62:OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.7
63:OpenGL core profile shading language version string: 4.50
64:OpenGL core profile context flags: (none)
65:OpenGL core profile profile mask: core profile
66:OpenGL core profile extensions:
147:OpenGL version string: 3.0 Mesa 17.0.7
148:OpenGL shading language version string: 1.30
149:OpenGL context flags: (none)
150:OpenGL extensions:
253:OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.0.7
254:OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
255:OpenGL ES profile extensions:
niklas @ niklas-tp : ~

[kirillbobyrev]

I also experience this issue.

OS: Arch Linux.
Compositor: Xorg
DE: KDE
Graphics: NVidia card + Nouveau

[intelfx]

@omtcyfz FTR, Xorg is neither a WM nor a compositor. Given that you use KDE, your compositing WM is likely to be KWin, but the usage of a compositor actually should prevent this issue, so it looks like you have compositing disabled or misconfigured in KWin.

[NickeZ]

@intelfx I'm using compton (which i believe is a compositor) and I3 and I still have the issue.

[FichteFoll]

Here's a video recording of this with i3 and compton (and Xorg):

alacritty_resize.zip

Without compton the situation is similar, except that the window is black instead of transparent. I doubt there's anything do be done here, though.

However, termite handles this better in that it seems to not be as eager with redrawing itself and only doing so when the number of columns or lines that can fit into the window change.

[chrisduerr]

So I've looked into this and it seems directly related to #969.

When using with_transparency(false), or just removing this call completely, this issue is not present anymore.

[FichteFoll]

Can confirm that this issue is basically non-existant with with_transparency(false).
It still looks kinda sub-optimal in ranger, but I suppose that ncurses is to blame for that or something. And I rarely resize a floating ranger window in i3 anyway.

Following is a working patch for the scrollback branch:

diff --git a/src/window.rs b/src/window.rs
--- a/src/window.rs
+++ b/src/window.rs
@@ -190,7 +190,7 @@
         Window::platform_window_init();
         let window = WindowBuilder::new()
             .with_title(title)
-            .with_transparency(true);
+            .with_transparency(false);
         let context = ContextBuilder::new()
             .with_vsync(true);
         let window = ::glutin::GlWindow::new(window, context, &event_loop)?;

[unphased]

Note as specified in #969 that this only affects High Sierra (and possibly Sierra) only. El Capitan performs great with transparency enabled.

[chrisduerr]

This has been fixed in winit 0.15.1.

[unphased]

Tested on macos 10.13.5 now, window resizing feels greatly improved!

dragging the corner to resize does make the window disappear temporarily as it always has, but performance is better overall.

[chrisduerr]

That's nice to hear! This issue was specifically about the window disappearing on X11, which has been fixed. I'm not sure if the MacOS behavior is tracked somewhere else.

[unphased]

Hmm. on my 2017 MacBook (I built master earlier yesterday) it is currently resizing very very sluggishly. Still gotta disable transparency to have resizing not sluggish. So maybe I was too quick on the draw with that report. Both machines tested on 10.13.5 though.

[chrisduerr]

Yeah, that is tracked in #969, macos definitely still has some issues with resizing.

Edit: Just noticed you created that issue, so you probably already know. :D