Foot Version

foot version: 1.25.0 -pgo +ime +graphemes -assertions

TERM environment variable

foot

Compositor Name and Version

labwc 0.9.3 (+xwayland +nls +rsvg +libsfdo)

Distribution

Void Linux

Terminal multiplexer

No response

Shell, TUI, application

zsh, vim, etc.

Server/standalone mode

• Standalone
• Server

Foot config

When switching between windows using labwc's built-in window switcher, foot's window thumbnail sometimes appears as a black window. I've noticed this issue only with foot, no other graphical application that I use on a daily basis shows this behavior.

Description of Bug and Steps to Reproduce

It's a little tricky to reproduce:

1. Run foot (server or standalone)
2. Use the compositor's window switcher
3. Repeat 1 until 2 is fullfiled

The issue is sporadic, I have not tested any other compositor besides labwc with a native window switcher.

I've attached a demo that shows the issue at 00:50 (seizure warning?: I switch very fast between windows)

Relevant logs, stacktraces, etc.

No response

foot version: 1.25.0 +pgo +ime +graphemes -assertions

TERM environment variable

xterm-256color

Compositor Name and Version

sway-1.11-r2

Distribution

Alpinelinux edge

Terminal multiplexer

tmux

Shell, TUI, application

bash

Server/standalone mode

• Standalone
• Server

Foot config

# -*- conf -*-

# shell=$SHELL (if set, otherwise user's default shell from /etc/passwd)
# term=foot (or xterm-256color if built with -Dterminfo=disabled)
# login-shell=no

font=DejaVu Sans Mono:size=12
pad=2x2                             # optionally append 'center'

[bell]
urgent=yes
notify=no

[url]
launch=wl-copy ${url}
label-letters=sadfjklewcmpgh
regex=(\b(https?|ftp|file)://[-A-Za-z0-9+&@#/%?=~_|!:,.;]*[-A-Za-z0-9+&@#/%=~_|])

[mouse]
hide-when-typing=yes

[colors]
foreground = aeadaf
background = 000000
regular0 = 232323
regular1 = d4823d
regular2 = 8c9e3d
regular3 = b1942b
regular4 = 6e9cb0
regular5 = 258d88
regular6 = 0da180
regular7 = 349d9f
bright0 = 012030
bright1 = d0913d
bright2 = 26a42d
bright3 = a8a030
bright4 = 0e9cc0
bright5 = d58888
bright6 = 3aa880
bright7 = aeadaf
selection-foreground = 049d9f
selection-background = 002030

Description of Bug and Steps to Reproduce

Well I just notice a high CPU usage of foot process (near 100% and peaks to 200/300%) when watching a big compilation. Decided to compare with alacritty and kitty where CPU usage is marginal, maybe peaks 3-5%, suppose that GPU helps there.. but then noticed I was testing with direct ssh instead mosh on foot. So switched to ssh on foot terminal and CPU droped a lot.

Just manually typing text I can reach 80-100% CPU usage on mosh/foot. Probably some known problem with foot/mosh internal design but I wanted to leave a record in case there was something more that could be fixed.

Regards!

Note: Just noticing that tmux has similar effect so probably it's just that tmux/mosh force foot to redraw the whole window all time.

1.25.0-1.fc43

TERM environment variable

xterm

Compositor Name and Version

KDE Plasma 6.4.3

Distribution

Fedora Toolbox 43 under SteamOS 3.9

Terminal multiplexer

No response

Shell, TUI, application

No response

Server/standalone mode

• Standalone
• Server

Foot config

# empty file

Description of Bug and Steps to Reproduce

Using KDE Plasma

distrobox enter
sudo dnf install foot

Default Wayland icon shows up only

Relevant logs, stacktraces, etc.

No response

This is sometimes caught in an assertion in term_destroy(), where we check the queue length is 0. Other times, or in release builds, we might crash in the thread, or in the shutdown logic when freeing the buffer chains associated with the terminal instance.

Fix by ensuring there's no pre-apply damage operation queued, or running, before shutting down a terminal instance.

Closes #2263