Glyphs scalling is not accurate

[kasper93]

Those are panes separators in tmux, as you can see after mentioned change vertical line is wider than horizontal one, which is in my opinion looks really bad, if you have direct comparison. Mintty does it right. The same font in both cases.

Before commit 70867df:

After commit 70867df:

Mintty:

[DHowett-MSFT]

It's not really wider, though, it's just brighter because we're not splitting it on the half pixel... that seems to be consistent with the traditional CP437 rendering of those glyphs (where the verticals are thicker than the horizontals)

[kasper93]

I took closeup look and counted pixels. Looks like it is 1px wider, but well, as you said it is also brighter, I though it looks brighter because it is wider and you say otherwise :)

Anyhow I didn't notice similar rendering in other terminal emulators. I mean I immediately noticed that something is wrong here. If you google tmux screenshots vertical and horizontal separators looks the same almost everywhere. I use the same font (Hack) in mintty and gnome terminal and looks fine.

[DHowett-MSFT]

Sorry - I didn't see the extra pixel because I trusted my browser's upscaler to use nearest-neighbor 😄

So, I'm going to resolve this one by design and file a followup work item. Before I do that, though, a bit of backstory and an explanation for why it is the way it is.

In the old terrible days, we could be relatively sure (cf. the traditional console's GDI renderer) that our font sizes were in absolute pixels. This left no possibility of fractional sizes for ascent, descent, or line spacing (as computed by the text layout engine.)

When we moved to using DirectWrite, we started to avail ourselves of the ability to do differential rendering and using an API that lets us only present changed regions (and do really fast scrolling by asking the graphics card to move the region for us.)

Those APIs only work on full pixel boundaries. Unfortunately, fonts are weird and when you try to render them in a nice grid sometimes you need to bump them around by fractional pixels. This didn't jive with the presentation API.

Terminal rounds a glyph's box size up to the nearest pixel, and adjusts the font size inside it for best fit. Doing this broke box/line drawing characters completely: they had gaps in the vertical direction, or gaps in the horizontal direction, because they no longer fit the cells we gave them. Whoops.

#5743 introduced a change that measures the four edges of a box or line glyph for any given font and scales it just a bit to touch the pixel-locked bounds we want to render it in. The result is consistent with the font's style, but stretched out a little bit in certain dimensions.

The tradeoff we made was to have contiguous box-drawing glyphs at the cost of having perfectly-sized box-drawing glyphs.

---

Other terminal emulators do interesting things:

• Gnome-terminal uses little 5x5 bitmaps and stretches them to fill the entire cell.
  • This results in pixel perfect boxes and shading.
• Konsole (KDE) uses line-drawing primitives at the graphics layer to mimic line drawing, and rect-filling primitives with opacity to mimic box drawing.
  • This also results in pixel-perfect boxes and cool blended shading glyphs.

We chose not to do these things for v1.0 because we learned that certain fonts (monofur is a good one) have their own unique styles for line glyphs (and box fills, but that's beside the point) that we wanted to preserve.

For post-v1, I'm willing to accept that this might not be the best way to handle it. I've filed a followup workitem, #5897, to encourage us to investigate different ways to handle these glyphs.

[DHowett-MSFT]

(The body of commit 70867df has more details about why we chose to do it this way. 😄)

[kasper93]

Thank you for comprehensive answer and creating followup work item 👍