Modified `start_classification` in `utf8_decode_to_esc` in `simd-string-impl.h`, which now:
Rejects `0xC0`, `0xC1` and `0xF5..0xFF` lead bytes in UTF-8 subsequences.
Enforces special ranges for the second subsequence bytes after `0xE0`, `0xED`, `0xF0` and `0xF4` bytes to prevent overlong sequences, surrogates, and code points above U+10FFFF.
Accumulates UTF-8 validation errors in a single vector to avoid many conditional branches.
Worsens unicode benchmark performance by about 4%.
Previously, if the last character was `'` parsing would fail: from `abc'`
it would produce the literal `'''abc''''`, which has one too many
unescaped single quote at the end.
This also fixes the issue for solo `'''`, where before it would produce
`''''\\'''''`, again with one too many single quote at the end.
I added tests for both cases.
This was needed to fix various corner cases when doing blending of colors
in linear space. The new architecture has the same performance as the
old in the common case of opaque rendering with no UI layers or images.
In the case of only positive z-index images there is a performance
decrease as the OS Window is now rendered to a offscreen texture and
then blitted to screen. However, in the future when we move to Vulkan or
I can figure out how to get Wayland to accept buffers with colors in
linear space, this performance penalty can be removed. The performance
penalty was not significant on my system but this is highly GPU
dependent. Modern GPUs are supposedly optimised for rendering to
offscreen buffers, so we will see. The awrit project might be a good
test case.
Now either we have 1-shot rendering for the case of opaque with only ext
or all the various pieces are rendered in successive draw calls into an
offscreen buffer that is blitted to the output buffer after all drawing
is done.
Fixes#8869
There are apparently some applications that want to only turn on OSC52
if they can be sure the terminal supports it.
https://github.com/contour-terminal/vt-extensions/blob/master/clipboard-extension.md
Seems harmless enough, though IMO the correct query mechanism for
runtime controllable settings is XTGETTCAP, but, let's be a
good citizen and co-operate. The overhead is not too large and I
have more important windmills to tilt at.
Fixes#8788
