This changes the half-circle drawing algorithm for glyphs E0B4 and E0B6
to an ellipse algorithm.
This fixes a shortcoming in the circle approach - how do you handle
drawing for a box that is not a typical 2:1 H*W? We were trying to
anticipate this by taking the smaller of the two axes and using that for
the radius. This works when there's some error in the zoom and the x
radius somehow becomes larger than the y radius (in observation, this
happens occasionally in some zoom steps, but only slightly).
However, turns out a more realistic anticipation is for fonts that have
a much *larger* height-to-width ratio. Iosevka, for example, has an
approx. 2.6:1 ratio (observed in the inspector). In this instance, this
approach does nothing except lock the circle to an extremely small
radius. For this instance, we need an ellipse, which will handle all
cases in an expected fashion.
Fixes#1050.
Fixes#1037
Renderers must convert the internal Kitty graphics state to a GPU
texture for rendering. For performance reasons, renderers cache the GPU
state by image ID. Unfortunately, this meant that if an image was
replaced with the same ID and was already cached, it would never be
updated on the GPU.
This PR adds the transmission time to the cache. If the transmission
time differs, we assume the image changed and replace the image.
Fixes#1014
There were a couple overlapping issues here:
1. To determine the "unshifted" key, we were using `keyval_to_lower`.
This only works if the key is uppercase and not all layouts are
uppercase for the unshifted value.
2. If we couldn't case the unicode value of a key or unshifted key to
ASCII, we'd say the key was the same as the physical key. This is
incorrect because the physical key is always the layout of the
physical keyboard so for example with the Turkish layout on a US
keyboard, you'd get US letters when a key may only correspond to
non-US letters.
To fix the first issue, we are using map_keycode to map the hardware
keycode to all possible keyvals from it. We then use the currently
active layout to find the unshifted value.
To fix the scond issue, we no longer fallback to the physical key if
there was IM text or non-ASCII unicode values for the key.
I tested Turkish with #1014 and I tested Dvorak to make sure those
basics still work.
With the nixpkgs LLVM 17 PR (NixOS/nixpkgs#258614) now merged, we can
update this flake input to base off of master so that we can take
advantage of the built LLVM derivation when it's ready.
This only leaves Zig 0.12 which should mean a much reduced build time.
Note that of this writing, the derivations are still queued, so until
that happens, this update means a rebuild of LLVM 17 for anyone using
the ghostty package.
