Wayland error + freeze until sigkilled when a large number of damage rectangles are attached to the surface's pending buffer #2338

lilyyy411 commented 2026年05月14日 23:37:09 +02:00

Foot Version

foot version: 1.26.1-13-gcc6b29fe (May 13 2026, branch 'master') -pgo +ime -graphemes +toplevel-tag +blur +assertions

TERM environment variable

foot

Compositor Name and Version

niri 26.04

Distribution

Linux Mint trixie/sid (xia)

Terminal multiplexer

No response

Shell, TUI, application

No response

Server/standalone mode

• Standalone
• Server

Foot config

default config

Description of Bug and Steps to Reproduce

In extreme cases where the pending buffer has an absolutely absurd number of damage rectangles (for me, it was around 9.9-10k), calls to [wl_surface_damage_buffer] in render.c grid_render() can cause a Wayland error Error sending request: Resource temporarily unavailable to be printed to the terminal. Then, as strace logs confirm, foot gets frozen attempting to constantly poll the Wayland socket and never receives an event again and requires being sigkilled to close the window.

This Wayland error comes from some internal limit on the number of damage rectangles that can be attached to a surface's pending buffer, but more importantly from the fact that foot does not currently attempt to optimize the number of damage rectangles given to the compositor. On a local clone, I was able to fix the bug and as a bonus, considerably boost foot's performance at high resolution in personal benchmarks, by implementing a naive greedy merging algorithm, and I'll make a PR when I get the chance.

You're probably wondering how the hell I even managed to get to 10k damage rectangles... I was writing my own terminal video player that renders with ASCII space characters as pixels so I could benchmark various terminals in sheer escape sequence parsing speed and foot was the only terminal that I tried that completely froze when the cell width became close to 1px.

Relevant logs, stacktraces, etc.

image
image

### Foot Version foot version: 1.26.1-13-gcc6b29fe (May 13 2026, branch 'master') -pgo +ime -graphemes +toplevel-tag +blur +assertions ### TERM environment variable foot ### Compositor Name and Version niri 26.04 ### Distribution Linux Mint trixie/sid (xia) ### Terminal multiplexer _No response_ ### Shell, TUI, application _No response_ ### Server/standalone mode - [x] Standalone - [x] Server ### Foot config ```ini default config ``` ### Description of Bug and Steps to Reproduce In extreme cases where the pending buffer has an absolutely absurd number of damage rectangles (for me, it was around 9.9-10k), calls to [`wl_surface_damage_buffer`] in `render.c` [`grid_render()`](<https://codeberg.org/dnkl/foot/src/branch/master/render.c#L3600-L3609>) can cause a Wayland error `Error sending request: Resource temporarily unavailable` to be printed to the terminal. Then, as strace logs confirm, foot gets frozen attempting to constantly poll the Wayland socket and never receives an event again and requires being sigkilled to close the window. This Wayland error comes from some internal limit on the number of damage rectangles that can be attached to a surface's pending buffer, but more importantly from the fact that foot does not currently attempt to optimize the number of damage rectangles given to the compositor. On a local clone, I was able to fix the bug and as a bonus, considerably boost foot's performance at high resolution in personal benchmarks, by implementing a naive greedy merging algorithm, and I'll make a PR when I get the chance. You're probably wondering how the hell I even managed to get to 10k damage rectangles... I was writing my own terminal video player that renders with ASCII space characters as pixels so I could benchmark various terminals in sheer escape sequence parsing speed and foot was the only terminal that I tried that completely froze when the cell width became close to 1px. ### Relevant logs, stacktraces, etc.  

dnkl commented 2026年05月15日 08:37:02 +02:00

This Wayland error comes from some internal limit on the number of damage rectangles that can be attached to a surface's pending buffer, but more importantly from the fact that foot does not currently attempt to optimize the number of damage rectangles given to the compositor.

We've so far relied on pixman's builtin merging in pixman_region32_union_rect(). But if we can improve upon it ourselves, that's great.

> This Wayland error comes from some internal limit on the number of damage rectangles that can be attached to a surface's pending buffer, but more importantly from the fact that foot does not currently attempt to optimize the number of damage rectangles given to the compositor. We've so far relied on pixman's builtin merging in `pixman_region32_union_rect()`. But if we can improve upon it ourselves, that's great.