New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alacritty blinks on resize #869

Closed
andreyorst opened this Issue Oct 26, 2017 · 13 comments

Comments

Projects
None yet
7 participants
@andreyorst

andreyorst commented Oct 26, 2017

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

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

@NickeZ

This comment has been minimized.

Contributor

NickeZ commented Oct 27, 2017

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 : ~
@kbobyrev

This comment has been minimized.

kbobyrev commented Oct 28, 2017

I also experience this issue.

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

@intelfx

This comment has been minimized.

intelfx commented Oct 30, 2017

@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

This comment has been minimized.

Contributor

NickeZ commented Oct 30, 2017

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

@FichteFoll

This comment has been minimized.

FichteFoll commented Dec 28, 2017

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

This comment has been minimized.

Collaborator

chrisduerr commented Jan 9, 2018

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

This comment has been minimized.

FichteFoll commented Jan 10, 2018

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

This comment has been minimized.

unphased commented Jan 22, 2018

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

@chrisduerr chrisduerr changed the title from [Linux] Alacritty blinks on resize to Alacritty blinks on resize May 4, 2018

@chrisduerr

This comment has been minimized.

Collaborator

chrisduerr commented Jul 15, 2018

This has been fixed in winit 0.15.1.

@chrisduerr chrisduerr closed this Jul 15, 2018

@unphased

This comment has been minimized.

unphased commented Jul 17, 2018

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

This comment has been minimized.

Collaborator

chrisduerr commented Jul 17, 2018

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

This comment has been minimized.

unphased commented Jul 22, 2018

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

This comment has been minimized.

Collaborator

chrisduerr commented Jul 22, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment