Repository navigation
gtk-ng: fix split change (new, delete, resize, etc.) "flicker"Â #8208
Description
Right now, new/close split cause a noticeable flicker, see #8202 for a video.
This is because we have to wait 1 or more event loop ticks for the surface widgets to unparent before building the new GtkPaned tree. We should be able to do this all in one frame, but every time I tried I hit rendering issues. I suspect I'm just messing things up with my [lack of] GTK knowledge.
Activity
apprt: make gtk-ng the default apprt on Linux (#8235)
busybox11 commentedon Nov 14, 2025
I believe I'm experiencing the same issue - not only on splits creation (which are much much slower to respond than in your video on my end), but also on window creation, when using Hyprland. Shows either a fully transparent or a semi-rendered surface (I believe upper side transparent, lower rendered?) for a split second.
Seems fine with GNOME? Tweaking GTK-related, window, CSD settings... do not change anything. Always reproductible no matter the config on Hyprland, even without background transparency.
jcollie commentedon Nov 14, 2025
We're already aware that it's reproducible on every setup. The speed of your system may make the flicker more or less noticeable. It's something deep in how GTK is handling the reshuffling of widgets when a new split is created that so far no one has figured out.
So for future people that encounter this bug, please no "me too" posts unless you have something more to offer than "it happens to me on X with Y".
Add a reaction to the 1st comment and subscribe if you want to follow along.
4 remaining items
deifactor commentedon Feb 23, 2026
An idea: is it possible to at least make the "flicker" take on the color of the terminal background (rather than the UI background) by having some solid-color widget behind the terminal that gets displayed as a backstop? I know basically nothing about GTK, just spitballing.
pktpls commentedon Feb 23, 2026
There is more to it than just the optical flicker - if you resize too fast with the keybind (e.g. keep the key pressed), it completely breaks the splits.
Edit: Actually I just tried to reproduce the breakage to make a video of it, but it doesnt seem to break anymore, just flickers.
mitchellh commentedon Feb 23, 2026
The core cause is that the way we handle split state changes is we rebuild the entire widget tree and reparent it. GTK does not like this, although fundamentally I don't see what we're doing wrong. We do the same with SwiftUI (admittedly a totally different GUI system of course) and it causes no issues whatsoever.
mitchellh commentedon Mar 4, 2026
I was able to fix this before 1.3. âĪïļ
apprt/gtk: reduce split-tree flicker by reusing leaf widgets
apprt/gtk: reduce split-tree flicker by reusing leaf widgets
chriscarpenter12 commentedon Mar 10, 2026
First time user of ghostty and testing on Ubuntu 24.04 with version 1.3.0 and I noticed a jarring background flash with opacity enabled. With opacity disabled it doesn't seem noticeable.
Merge upstream-main into main (#34)
deifactor commentedon Apr 30, 2026
I'm also getting a background flash (easily noticeable when setting background-opacity to something like 0.99) when I open a new tab on 1.3.0 on NixOS unstable, and creating/destroying splits seems to cause a kind of "flicker" where the split renders in the wrong place. It's better than before #11170 merged for sure, but it's still noticeable.
gtk: improve split sizing (#13414)