gtk: flickering on resize

[plichard]

flicker.mp4

ghostty version: 0.1.0-main+9d341a9f

Built from source with zig build -p $HOME/.local -Doptimize=ReleaseFast.

# Needed to install these packages:
$ dnf info gtk4-devel libadwaita-devel libXtst-devel
Last metadata expiration check: 0:58:20 ago on mer 16 oct 2024 12:01:46.
Installed Packages
Name         : gtk4-devel
Version      : 4.14.5
Release      : 1.fc40
Architecture : x86_64
Size         : 23 M
Source       : gtk4-4.14.5-1.fc40.src.rpm
Repository   : @System
From repo    : updates
Summary      : Development files for GTK
URL          : https://www.gtk.org
License      : LGPL-2.0-or-later
Description  : This package contains the libraries and header files that are needed
             : for writing applications with version 4 of the GTK widget toolkit.

Name         : libXtst-devel
Version      : 1.2.5
Release      : 1.fc40
Architecture : x86_64
Size         : 12 k
Source       : libXtst-1.2.5-1.fc40.src.rpm
Repository   : @System
From repo    : updates
Summary      : X.Org X11 libXtst development package
URL          : http://www.x.org
License      : MIT-open-group AND HPND-sell-variant AND X11 AND HPND-doc AND HPND-doc-sell
Description  : X.Org X11 libXtst development package

Name         : libadwaita-devel
Version      : 1.5.4
Release      : 1.fc40
Architecture : x86_64
Size         : 2.1 M
Source       : libadwaita-1.5.4-1.fc40.src.rpm
Repository   : @System
From repo    : updates
Summary      : Development files for libadwaita
URL          : https://gitlab.gnome.org/GNOME/libadwaita
License      : LGPL-2.1-or-later AND MIT
Description  : Development files for libadwaita.

Operating System: Fedora Linux 40
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.2
Kernel Version: 6.10.12-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62,7 GiB of RAM
Graphics Processor: AMD Radeon RX 6600
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B93
System Version: 1.0

[mitchellh]

This is specific to Linux and I'm not entirely sure how to resolve it. On macOS we have a "content gravity" API that informs Cocoa/AppKit how to handle the Metal surface during resize (stretch, no stretch, etc) and so we can use that to handle the drawing state between resizes and redraws. I'm not aware of an equivalent in GTK4.

Fundamentally, the issue is probably related to the fact that our terminal IO and rendering happen on different threads, so from a live resize => termio/pty update => renderer redraw it could be taking more than 1 frame and causing jitter like this. The content gravity work on macOS papers over this.

Synchronously doing a terminal state resize AND redraw on live resize seems too expensive, specifically the terminal state part. What we probably want to do is do a synchronize renderer frame update with the new viewport size but old grid size to artificially create our content gravity effect.

Or, maybe this isn't the problem at all.

[GoldsteinE]

Possibly related: on fast resize caused by re-tiling of a tiling WM, ghostty looks “stretched” while resizing.

recording.mp4

[renegadevi]

This is specific to Linux and I'm not entirely sure how to resolve it. On macOS we have a "content gravity" API that informs Cocoa/AppKit how to handle the Metal surface during resize (stretch, no stretch, etc) and so we can use that to handle the drawing state between resizes and redraws. I'm not aware of an equivalent in GTK4.

Fundamentally, the issue is probably related to the fact that our terminal IO and rendering happen on different threads, so from a live resize => termio/pty update => renderer redraw it could be taking more than 1 frame and causing jitter like this. The content gravity work on macOS papers over this.

Synchronously doing a terminal state resize AND redraw on live resize seems too expensive, specifically the terminal state part. What we probably want to do is do a synchronize renderer frame update with the new viewport size but old grid size to artificially create our content gravity effect.

Or, maybe this isn't the problem at all.

On MacOS. I also get flickering on resize. Could be a different cause of reason. On video, Alacritty, Ghostty and iTerm2
https://github.com/user-attachments/assets/6a1e42ec-df75-43a9-a40d-eb5199602203

[marbaa]

Hopefully, this flickering will be removed anytime. Konsole, Gnome Terminal, Ptyxis doesn't flicker.

I found other pretty big visual bug while resizing, but that might be for other issue.
v1.0.1 built from source.

[tmmorin]

I observed the same behavior on Gnome (flickering due to the image being temporarily stretched by Gnome window manager before Ghostty redraws the window very soon after).

And indeed as mentioned above this does not happen with gnome-terminal.

Interestingly, gnome-terminal behavior on resize is that resize isn't continuous: the window "snaps to grid", i.e. even with a smooth window corner drag, it increases only by discrete increments corresponding to the terminal character size.

2025-01-02.22-19-40.mp4

This naturally avoids any kind of flickering that could arise if window content had to continuously follow the drag.

Ghostty actually seems to have the ability to resize with discrete increments: window-step-resize.
Unfortunately, this isn't implemented for Linux (doc says "Currently only supported on macOS.").

If window-step-resize was implemented for Linux, then using it would avoid this flicker issue (and could be considered for being enabled by default).

[tmmorin]

If it can help, the ways this is done in gnome-terminal/GTK via libvte is that it sets the GDK_HINT_RESIZE_INC window geometry hint..

[mitchellh]

@tmmorin Beware, VTE is GPL so we have to be careful about looking at their source. You can describe what they do but I edited your comment to remove the link.

[dnut]

Interestingly, gnome-terminal behavior on resize is that resize isn't continuous: the window "snaps to grid", i.e. even with a smooth window corner drag, it increases only by discrete increments corresponding to the terminal character size.

gnome-console, the replacement for gnome-terminal, does not have this discrete stepping behavior. It resizes pixel-by-pixel. The same is true for tilix (another terminal designed for gnome). Neither of them have this flickering issue.

[tmmorin]

@dnut:

Interestingly, gnome-terminal behavior on resize is that resize isn't continuous: the window "snaps to grid", i.e. even with a smooth window corner drag, it increases only by discrete increments corresponding to the terminal character size.

gnome-console, the replacement for gnome-terminal, does not have this discrete stepping behavior. It resizes pixel-by-pixel. The same is true for tilix (another terminal designed for gnome). Neither of them have this flickering issue.

I intended to point out that window-step-resize, if implemented on Linux would be a possible workaround, in particular if implementing the nicest solution ends up not being trivial.

But yes, adopting the same behavior would certainly be the best.

[pluiedev]

GDK_HINT_RESIZE_INC is GTK/GDK3 only: https://docs.gtk.org/gdk3/flags.WindowHints.html. It's most likely because GTK4 removed a lot of APIs that only made sense for X11 and not Wayland, and Wayland doesn't offer any mechanism for step resizing.