This is more correct: a pagelist is a linked list of nodes, not pages.
The nodes themselves contain pages but we were previously calling the
nodes "pages" which was confusing, especially as I plan some future
changes to the way pages are stored.
Some Intel MacBook Pro laptops have both an integrated and discrete
GPU and support automatically switching between them. The system
uses the integrated GPU by default, but the default Metal device on
those systems is the discrete GPU. This means that Metal‐using
applications activate it by default, presumably as the intended
audience is high‐performance graphics applications.
This is unfortunate for productivity applications like terminals,
however, as the discrete GPU decreases battery life and worsens the
thermal throttling problems these machines have always had. Prefer
to use an integrated GPU when present and not using an external GPU.
The behaviour should be unchanged on Apple Silicon, as the platform
only supports one GPU. I have confirmed that the resulting app runs,
works, and doesn’t activate the AMD GPU on my MacBook Pro, but have
not done any measurements of the resulting performance impact. If
it is considered sufficiently noticeable, a GPU preference setting
could be added.
See <https://github.com/zed-industries/zed/issues/5124>,
<https://github.com/zed-industries/zed/pull/13685>,
<https://github.com/zed-industries/zed/pull/14738>, and
<https://github.com/zed-industries/zed/pull/14744> for discussion,
measurements, and changes relating to this issue in the Zed
project. The logic implemented here reflects what Zed ended up
settling on.
The [Metal documentation] recommends using
`MTLCopyAllDevicesWithObserver` to receive notifications of when
the list of available GPUs changes, such as when [external GPUs
are connected or disconnected]. I didn’t bother implementing that
because it seemed like a lot of fussy work to deal with migrating
everything to a new GPU on the fly just for a niche use case on a
legacy platform. Zed doesn’t implement it and I haven’t heard
about anyone complaining that their computer caught fire when they
unplugged an external GPU, so hopefully it’s fine.
[Metal documentation]: https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/multi-gpu_systems/finding_multiple_gpus_on_an_intel-based_mac
[external GPUs are connected or disconnected]: https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/multi-gpu_systems/handling_external_gpu_additions_and_removalsCloses: #2572
Significant rework that also removes a lot of unnecessarily duplicated
work while rebuilding cells in both renderers. Fixes multiple issues
with decorations and bg colors on wide chars and ligatures, while
reducing the amount of special case handling required.
Metal needed to be changed to account for wide chars having decorations
on the right half and OpenGL needed to account for multiple glyphs being
under the cursor at once (decorations and combining marks) as well as
wide chars.
This makes sure that underline styles are consistent and not stretched,
and avoids rendering overlapping text decorations or extraneous
background cells for the right halves of wide chars.
Metal already had this change made, so I copied it over from there. This
logic is more straightforward. Also copied the check to skip 0-sized
glyphs, since sometimes, for example, spaces are emitted as glyphs by
the shaper for some reason, even though they have no actual content, and
we want to avoid sending a bunch of useless stuff to the GPU.
This commit refactors RepeatablePath to contain a list of tagged unions
containing "optional" and "required" variants. Both variants have a null
terminated file path as their payload, but the tag dictates whether the
path must exist or not. This implemenation is used to force consumers to
handle the optional vs. required distinction.
This also moves the parsing of optional file paths into RepeatablePath's
parseCLI function. This allows the code to be better unit tested. Since
RepeatablePath no longer contains a simple list of RepeatableStrings,
many other of its methods needed to be reimplemented as well.
Because all of this functionality is built into the RepeatablePath type,
other config options which also use RepeatablePath gain the ability to
specify optional paths as well. Right now this is only the
"custom-shaders" option. The code paths in the renderer to load shader
files has been updated accordingly.
In the original optional config file parsing, the leading ? character
was removed when paths were expanded. Thus, when config files were
actually loaded recursively, they appeared to be regular (required)
config files and an error occurred if the file did not exist. **This
issue was not found during testing because the presence of the
"theme" option masks the error**. I am not sure why the presence of
"theme" does this, I did not dig into that.
Now because the "optional" or "required" state of each path is tracked
in the enum tag the "optional" status of the path is preserved after
being expanded to an absolute path.
Finally, this commit fixes a bug where missing "config-file" files were
not included in the +show-config command (i.e. if a user had
`config-file = foo.conf` and `foo.conf` did not exist, then `ghostty
+show-config` would only display `config-file =`). This bug applied to
`custom-shaders` too, where it has also been fixed.
- move wuffs code from src/ to pkg/
- eliminate stray debug logs
- make logs a warning instead of an error
- remove initialization of some structs to zero
Improve the performance of Kitty graphics by switching to the WUFFS
library for decoding PNG images and for "swizzling" G, GA, and RGB data
to RGBA formats needed by the renderers.
WUFFS claims 2-3x performance benefits over other implementations, as
well as memory-safe operations.
Although not thorougly benchmarked, performance is on par with Kitty's
graphics decoding.
https://github.com/google/wuffs
Before, cells that were explicitly set to match the default bg color
were treated as if they did NOT have the default and extending would
occur. We now check the exact RGB of each cell.
Fixes#2099
This is another heuristic of sorts to make `window-padding-color=extend`
look better by default. If a fully covering glyph is used then we use
the fg color to extend rather than the background.
This doesn't account for fonts that may do this for whatever codepoints,
but I think that's a special scenario that we should just recommend
disabling this feature.
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.
This happened to work in releases somehow but Xcode debug builds would
catch this as an assertion. Our cell bg pipeline now uses the "full
screen vertex shader" which takes no parameters, so we don't need a
vertex descriptor.
