Before this fix, if vsync was on the GPU cells buffer could be cleared
for a frame while resizing the terminal down. This was due to the fact
that the surface sent messages for the resize to both the renderer and
the IO thread. If the renderer thread was processed first then the GPU
cells buffer(s) would be cleared and not rebuilt, because the terminal
state would be larger than the GPU cell buffers causing updateFrame to
bail out early, leaving empty cell buffers.
This fixes the problem by changing the origin of the renderer's resize
message to be the IO thread, only after properly updating the terminal
state, to avoid clearing the GPU cells buffers at a time they can't be
successfully rebuilt.
Fixes#2081
Many fonts have a bad ligature for "fl", "fi", or "st". We previously
maintained a list of such fonts in quirks.zig. However, these are so
common that it was suggested we do something more systematic and this
commit is that.
This commit changes our text run splitting algorithm to always split on
`fl`, `fi`, and `st`. This will cause some more runs for well behaved
fonts but the combination of those characters is rare enough and our
caching algorithm is good enough that it should be minimal overhead.
This commit renders our existing quirks fonts obsolete but I kept that
logic around so we can add to it if/when we find other quirky font
behaviors.
To protect your system and ghostty from misbehaving programs that launch
too many processes for the system to handle (e.g. like a fork bomb),
this implements an option to limit the number of processes that can be
started in a surface.
A fork bomb for example or other misbehaving program would then only
take down one surface and not the entire system.
Side node:
If I am right in issue #2084, this feature does not actually work on a
per surface basis but on all surfaces. If this is the case, it could
probably be fixed together. Chances are, that I am wrong though 😉
Further improvements that could be done:
- unify way to set cgroup attributes
- set sane default: 10% of system max?
I noticed that the HashMap iterator showed up prominently in Instruments when quickly
resizing Ghostty.
I think this is related to the [tombstone issue](https://github.com/ziglang/zig/issues/17851),
where the `next()` function has to skip unused meta-nodes.
In that same issue, Andrew is suggesting that the non-array hashmap might get deleted from the
standard library.
After switching to `AutoArrayHashMapUnmanaged`, iteration barely shows up anymore.
Deletion from the pin list should also be fast as swapRemove is used (order does not need to be preserved).
Question is if insertion performance is negatively affected, though I'm not seeing anything obvious.
Still, checking this PR for any perf regressions might be a good idea.
If this pans out, there are more places where this switch might be beneficial.
