Michael Stapelberg

I think we should prioritize this issue. Especially with larger displays (e.g. 8K displays), the memory usage is noticeable. xrestop(1) shows that my i3 process clocks in at 2538396168 pixmap...

I might be able to spend a little time on it, but don’t want to make any promises. If anyone would race me to it, that’d be appreciated :)

Applied the following quick hack to verify resource usage is actually due to pixmaps: ```diff diff --git i/src/x.c w/src/x.c index f643a9b3..a6c8c0e4 100644 --- i/src/x.c +++ w/src/x.c @@ -963,6 +963,10 @@...

Reported GPU memory usage by `nvidia-smi -q -d pids,memory` is still pretty high (for the Xorg process), so I’m not sure whether this change actually makes a dent in the...

I have run into slowdowns even with the patch, so at least it’s not the primary cause. We should still do it, but there’s no big urgency, at least not...

I agree with @Airblader on this. Thanks for taking a look!

> I assume that the extra memory is caused by all the windows that are created and stacked underneath the visible one. It should be easy to confirm this by...

> we'd have to update all sections for all languages to mark them as up to date, right The `tl8-flag` tool automatically marks sections as outdated in translations when they...

As an Emacs user myself, I’m sympathetic to the idea of major/minor modes, but at the same time, I’m worried about making this area of i3 more complex than it...

Sounds good in principle. Using unique identifiers (e.g. returned by the exec command via IPC) would increase robustness, but slightly decrease convenience. Maybe if the identifier is empty, we’ll return...