Add sextant glyph support to terminal rendering

[mchisolm0]

The Zed integrated terminal shows a broken QR code for apps with Expo SDK 55. This PR custom-paints the terminal block and sextant glyphs used for QR codes rather than relying on font glyphs.

SDK 55 Before	SDK 55 After	SDK 55 in Ghostty

Other notes

• Expo recently merged fix(cli): Disable sextant QR code rendering for Zed expo/expo#46148, which causes Expo SDK 56 to fall back to the old QR code behavior when used in Zed. Once this PR merges, Expo can remove that fallback and use the compact QR code path in Zed again for Expo SDK 56+.

Current Fallback QR Code for SDK 54 and 56	Fallback with this PR

This PR now also fixes TUIs in the integrated terminal for users using some fonts.

OpenCode w/ Monaco before change	OpenCode w/ Monaco after change

Finally, shade characters are now handled in the integrated terminal.

btop with tty graph before change	btop with tty graph after change

This PR

• Adds custom painting for terminal bitmap glyphs used by QR renderers: █, ▀, ▄, ▌, ▐, and U+1FB00..U+1FB3B sextants
• Adds tests for handling sextants, blocks/half-blocks, and adjacent block merging

Closes #50158
Closes #58830

Before you mark this PR as ready for review, make sure that you have:

• Added a solid test coverage and/or screenshots from doing manual testing
• Done a self-review taking into account security and performance aspects
• Aligned any UI changes with the UI checklist

Release Notes:

• Fixed QR code rendering for Expo SDK 55 apps
• Fixed rendering TUIs in the integrated terminal for some users

[mchisolm0]

I have verified the changes fix the broken QR code. I still need to look closer at the changes after some sleep, so it is still a draft.

Screenshot of QR code working

Steps to verify fix

1. Start a new Expo app with SDK 55 using npx create-expo-app@latest --template default@sdk-55 or bun create expo-app --template default@sdk-55
2. Checkout this branch
3. Run cargo run [app-dir-from-step-1]
4. Run npm run start or bun run start in the Zed integrated terminal
5. Scroll to see where the QR code is (should render correctly)

[mchisolm0]

Performance

Histogram of performance between sextant glyphs and main

Security

I cannot think of a place in the PR that would be a security concern. Please let me know if there is one.

[2manslkh]

Please fix this thank you!

[mchisolm0]

I believe I understood the changes @/benbrandt made in #57483 to now use a neutral terminal backend and updated the addition of sextant glyphs for Expo SDK 55+ QR codes correctly. Just wanted to mention it for context.

[mchisolm0]

I have updated the PR description to reflect the most recent changes I've made. The first fix left gaps in the seams of the QR code. If this is not the direction the Zed team wants to go, I am happy to close this PR and go a different direction.

[SomeoneToIgnore]

Sorry, slowly trying to reproduce the root issue.
For me, seems that expo in its latest versions exposes no issues anymore and both the PR and the issue could be closed?

[mchisolm0]

@SomeoneToIgnore Thanks for checking. You are right that we no longer see the issue reported in #50158 because expo has made an exception for Zed to fallback to the old QR code rather than their new sextant based QR code. This PR does fix the sextant QR code if expo decides to bring it back for Zed in the future.

Also, it seems this PR fixes other issues with glyphs in the integrated terminal like in #58830 where some fonts render gaps in TUIs like Opencode.

Monaco before change	Monaco after change

Based on #17904 and #27559, the Zed team seems to prefer these are fixed with line_height set to a custom value.

"terminal": {
    "line_height": {
      "custom": 1.3
    },
    "font_family": "PT Mono"
  }

If that is the preference and you feel expo falling back to the old QR code method is sufficient then I agree we can close this PR.

Examples

	Before Change	After Change
Sextant QR code (SDK 55)
Old QR code w/ Monaco (SDK 57)
Open code w/ Monaco

[SomeoneToIgnore]

In that case, I found it quite odd that we did not support a better range of symbols — pushed that into the PR along with the drive-by fix for the quadratic merge_background_regions when pushing regions for █.

Can you check that my changes make sense?
Anything else you would have wanted to push in that direction?

[mchisolm0]

Thank you for the changes. It took me a bit to wrap my head around them, but now I think it's much easier to understand how the characters end up mapping to the terminal subcells. I think the added symbols are good and avoiding unnecessary calls to merge_background_regions is a great catch.

I don't think there is anything I want to add to this PR. I found some other problems with glyphs and powerlines as mentioned #51310, but I think that would be a separate PR if the team decides to implement the suggestions. It does look like this PR addresses some of the initial requests in the feature request, though.

I have updated the PR description to reflect the new changes. I asked if the author of #56342 agrees this fixes their main concern or if they were requesting every Unicode in that range be handled.

Unless you need anything else, I am happy for you to merge this.

[SomeoneToIgnore]

Great, thank you a lot for confirming!