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
adw_application_window_destroy and gtk_application_window_destroy do not
exist. I believe that this didn't trigger a compile error because the
errdefer got compiled out because there are no potential error returns
after this code in the function.
The explanation now refers to RFC 793 instead of just claiming some
arbitrary value as truth. The previous value was correct, but now there
is a proper source for the correct value.
Fixes#2537
This matches Terminal.app. iTerm2 requires cmd+option (our old
behavior). Kitty doesn't seem to support rectangle select or I couldn't
figure out how to make it work. WezTerm matches Terminal.app too.
Outside of terminal emulators, this is also the rectangular select
binding for neovim.
When resetting the terminal screen, the memory buffer allocated for the
scrollback is now cleared by reinitializing the screen and falling back to the
current method if any of the attempts to reinitialize fail.
Closes#2464
Fixes#2500
Based on #2508
This separates out the concept of a "hyperlink" from a "hyperlink page
entry." The difference is that the former has real Zig slices into
things like strings and the latter has offsets into terminal page
memory.
From this separation, the Page structure now has an `insertHyperlink`
function that takes a hyperlink and converts it to a page entry.
This does a couple things: (1) it moves page memory management out of
Screen and into Page which is historically more appropriate and (2) it
let's us more easily test hyperlinks from the Page unit tests.
Finally, this PR makes some error sets explicit.
Fixes#2499
We rely on CoreText's font discovery to find the best font for a
fallback by using the character set attribute. It appears that for some
codepoints, the character set attribute is not enough to find a font
that supports the codepoint.
In this case, we use CTFontCreateForString to find the font that
CoreText would use. The one subtlety here is we need to ignore the
last resort font, which just has replacement glyphs for all codepoints.
We already had a function to do this for CJK characters (#1637)
thankfully so we can just reuse that!
This also fixes a bug where CTFontCreateForString range param expects
the range length to be utf16 code units, not utf32.
