Add support for soft fonts in the DX renderer #13362
Conversation
| { | ||
| // We need to reset the clipping rect applied by the CustomTextRenderer, | ||
| // since the soft font will want to set its own clipping rect. | ||
| RETURN_IF_FAILED(_customRenderer->EndClip(_drawingContext.get())); |
There was a problem hiding this comment.
Is this necessary? The only place you push a clip, you've got a scope_exit to pop it. I don't think you're otherwise setting _clipRect anywhere, but maybe I'm mistaken. Maybe we need this just to make sure there's not already a clip rect
There was a problem hiding this comment.
It's not the soft font clipping that I'm worried here about - it's the CustomTextRenderer. It has a clipping rect that it keeps active until the end of the paint, only updating it when necessary. See here:
terminal/src/renderer/dx/CustomTextRenderer.cpp
Lines 514 to 515 in 0154da5
By calling EndClip, we clear that rect so we can apply our own. The CustomTextRenderer will then reapply its rect when it needs it.
zadjii-msft
added
the
AutoMerge
|
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
merged commit 
There are a bunch of soft fonts you can download here: But they're designed for an 8-bit terminal, so you need to switch to ISO-2022 mode first with the DOCS sequence: After that you can just There's also the CMatrix fork which uses soft fonts to produce the Japanese characters here: Just remember that if you want to test in Windows Terminal you have to use the passthrough mode for now. |
|
|
||
| // The bitmap and associated scaling/coloring effects are created on demand | ||
| // so we need make sure they're generated now. | ||
| RETURN_IF_FAILED(_createResources(d2dContext.Get())); |
There was a problem hiding this comment.
I haven't made it all the way through, but how do we handle device invalidation? Are the bitmaps okay to use cross-Context if we end up having to regenerate the context in the main renderer?
There was a problem hiding this comment.
Nevermind. Reset very obviously does that, and it happens to be called from releaseDeviceResources. Derp. Thanks.
This PR introduces a mechanism for passing through downloadable soft fonts to the conpty client, so that we can support DRCS (Dynamically Redefinable Character Sets) in Windows Terminal. Soft fonts were first implemented in conhost (with the GDI renderer) in PR #10011, and were implemented in the DX renderer in PR #13362. The way this works is by passing through the `DECDLD` sequence containing the font definition, but with the character set ID patched to use a hardcoded value (this is to make sure it's not going to override the default character set). At the same time we send through an `SCS` sequence to map this character set into the G1 table so we can easily activate it. We still need to process the `DECDLD` sequence locally, though, since the initial character set mapping take place on the host side. This gets the DRCS characters into our buffer as PUA Unicode characters. Then when the VT engine needs to output these characters, it masks them with `7F` to map them back to ASCII, and outputs an `SO` control to activate the soft font in the conpty client. ## Validation Steps Performed I've manually tested with a number of soft fonts and applications that make use of soft fonts. But if you're testing with the VT320 fonts from the vt100.net collection, note that you'll need to enable the ISO-2022 coding system first, since they use 8-bit C1 controls.
|
🎉 Handy links: |
Summary of the Pull Request
This PR adds support for downloadable soft fonts in the DirectX
renderer, potentially enabling them to be used in Windows Terminal.
References
Soft fonts were first implemented in conhost (with the GDI renderer) in
PR #10011.
PR Checklist
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx
Detailed Description of the Pull Request / Additional comments
The way the DirectX implementation works is by building up a bitmap
containing all of the glyphs, and then drawing an appropriate subsection
of that bitmap for each character that needs to be rendered. The current
text color is applied with a color matrix effect, and the glyphs are
automatically scaled up to the current font size with a scaling effect.
By default the scaling uses a high quality cubic interpolation, which
gives it a smoother antialiased effect. But if the Text antialiasing
option is configured as Aliased, we use a simpler nearest-neighbor
interpolation, which more closely matches the rendering of the original
GDI implementation.
Validation Steps Performed
I've manually tested the renderer in conhost with the
UseDxregistryentry. I've also tested in Windows Terminal using the experimental
passthrough mode.