It's unfortunate that we're keen on replacing the DX engine here! Thanks for doing all of this. @lhecker we should consider how we'll represent glyphs in the atlas that take up more vertical space than one row (!)

It's unfortunate that we're keen on replacing the DX engine here! Thanks for doing all of this. @lhecker we should consider how we'll represent glyphs in the atlas that take up more vertical space than one row (!)

I haven't really looked at the Atlas renderer, because I assumed I would be a bit out of my depth there, but I had hoped that the line-rendition support I added to the DX renderer could be ported fairly easily by someone that knew what they were doing.

And I wouldn't think you'd need to do anything special in the atlas if you're taking the same approach - it's just a transform that's applied when each line is rendered.

And I wouldn't think you'd need to do anything special in the atlas if you're taking the same approach - it's just a transform that's applied when each line is rendered.

Possibly. The core conceit of atlas is that we rasterize each [glyph * font] combo one time into a GPU texture and then use a pixel shader to copy and color the glyph mask directly to the render target. I think if we approach line renditions the same way as we do in DX, we may end up with scaling artifacts.

My gut tells me that we'll want to do the transform in the early phase when we're producing the glyph texture, and somehow mark that glyph as requiring multiple cells much like we would if it were multi-width. Hmm...

I think if we approach line renditions the same way as we do in DX, we may end up with scaling artifacts.

Yeah, I just realised that after I posted my reply. But I'd personally be perfectly happy with that as a solution. It's certainly better than nothing. Obviously this is just me, but right now most of my use cases for double-size text involve soft fonts, which have a fixed resolution anyway, so they're always going to be scaled.

On that note, I should mention that I have a plan for soft font support over conpty which I'd like to create a PR for at some point. And again I'm hoping someone smarter than me will be able to port the DX implementation to Atlas so we can have soft fonts working there too.

My gut tells me that we'll want to do the transform in the early phase when we're producing the glyph texture, and somehow mark that glyph as requiring multiple cells much like we would if it were multi-width.

Thinking about this some more, double-height glyphs may not actually be a problem, because you only ever render one half of the glyph at a time (i.e. the top is rendered independently of the bottom). So the only additional functionality I think you might need would be some extension to the ID to distinguish between variants of a particular character (single width, double-width, double-height top, double-height bottom).

And this is assuming the atlas can already handle glyphs that are multiple cell widths, and not just double width, because any existing double width character, would now potentially be quadruple width.

Ah, right! It's actually just the tops and bottoms of the glyphs cleverly rendered next to eachother.

We do have support for glyphs that are >2 cells in width today; that's how we ended up implementing ligatures! That does mean that Cascadia's "infinite arrow" ligatures are, ah, expensive in terms of glyph space... but what can you do?

Glyph atlas with an infinite arrow

Each version of the ligature is rendered in full into the texture.

screen

atlas

Yep I'll gladly port everything over to AtlasEngine if you don't feel comfortable with it. Now that the new engine is sorta useable, I'm currently in the process of cleaning up that project to be better structured and easier to deal with.

For context:

• cells: A 3 cell wide glyph reserves 3 equally large cells in the texture atlas. The cells array stores those texture coordinates. The cells in the texture atlas aren't necessary next to each other, but the pixel shader will bit-blit them to appear next to each other on the screen.
• cellCount: The number of cells a glyph owns (in this example it's 3).
• CellFlags: Stores glyph and cell-specific attributes, like is-italic/intense/underlined/overlined/etc.

I'm planning to add double-height glyphs as a flag to CellFlags. If that flag is set, then the cells array stores twice as many entries as the cellCount indicates. All the existing code that assumes that the cellCount equals the width of the glyph in cells will continue to work. But if we encounter a double-height-line-rendition row then we will use the second half of the cells array to copy over another cellCount-many cells over into the lower half of the double-height row.

But if we encounter a double-height-line-rendition row then we will use the second half of the cells array to copy over another cellCount-many cells over into the lower half of the double-height row.

Just FYI, that's not how double-height rendition works. The top and bottom are completely independent and don't necessarily match. So you can have the top half of the letters ABC over the bottom half of XYZ. Or say one line being just the bottom half of the characters with single height lines above and below. You can mix and match line attributes however you want.

So in the same way that you have variants of each character for italic and bold, etc. I'd assume you'd also have double-width, double-height top, and double-height bottom variants. Then when rendering a line with the DoubleHeightTop attribute, you'd use the corresponding top variant for all the characters in that line. What appears on the following line is irrelevant.

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

🎉Windows Terminal Preview v1.17.1023 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download