6 ms·

The font, m8, the font. Use monospcae font and it works like a charm.

avereveard 5y ago
I haven't changed anything, just downloaded and launched, that's the result. if the term only works with one font why is the software picking a random one from the system conf?
- deleted 5y ago
  [deleted]
- mwcampbell 5y ago
  It looks like refterm is hard-coded to use Cascadia Mono, which isn't included in-box with Windows 10. So I don't know what happens if you don't have that font. If that's the only issue, then I think we can let that one go, as refterm is clearly only a proof of concept, and one-time logic for choosing the correct font at startup would presumably have no effect on rendering speed.
  - avereveard 5y ago
    https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png no, doesn't work with cascadia either. so what now?
    - mwcampbell 5y ago
      I suspect an i18n issue. What locale are you using, and what is the decimal separator character supposed to be in your locale?
      - avereveard 5y ago
        https://i.imgur.com/WrsVwFz.png https://i.imgur.com/WrsVwFz.png absolutely standard
        mwcampbell 5y ago
        It looks like your "Digit grouping symbol" field is empty. I'm sure that's standard in some locales, though not for US English. I don't know how to make that field empty; when I try, Windows says it's invalid. So I wonder if your locale sets that separator to some kind of Unicode character that, in a proper renderer, is equivalent to no character at all. If that's the case, then I'm guessing refterm could handle that character as easily as it handles VT escape codes. But this does lend some weight to the position that Casey was oversimplifying things a bit.
        maficious 5y ago
        well, whatever is different in your settings, mine renders normal https://imgur.com/dGI5W2S https://imgur.com/dGI5W2S EDIT: I am sorry for the attitude, changed "wrong" to "different"
        mwcampbell 5y ago
        Their settings aren't wrong, just different, likely because of differing standards for digit grouping across locales. So this is a case that refterm clearly doesn't support. This case by itself doesn't invalidate refterm's approach to rendering, but I can see why the team at Microsoft, knowing that there are many such cases, would favor abstraction over the absolute best possible speed.
        avereveard 5y ago
        which is exactly the point.
mwcampbell 5y ago
Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.
- vermilingua 5y ago
  This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?
  - onion2k 5y ago
    This is exactly the sort of "we can just skip that feature to make it faster!" edge case that I was talking about in my post.
    - vermilingua 5y ago
      But it isn't an edge case! It's not an edge case, if it isn't a use case! This is an edge case as much as building a rasterizer directly into the terminal is an "edge case".
      - l30n4da5 5y ago
        > But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.
        fouric 5y ago
        Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be". The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts. That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.
deleted 5y ago
[deleted]

I haven't changed anything, just downloaded and launched, that's the result. if the term only works with one font why is the software picking a random one from the system conf?

deleted 5y ago
[deleted]
mwcampbell 5y ago
It looks like refterm is hard-coded to use Cascadia Mono, which isn't included in-box with Windows 10. So I don't know what happens if you don't have that font. If that's the only issue, then I think we can let that one go, as refterm is clearly only a proof of concept, and one-time logic for choosing the correct font at startup would presumably have no effect on rendering speed.
- avereveard 5y ago
  https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png no, doesn't work with cascadia either. so what now?
  - mwcampbell 5y ago
    I suspect an i18n issue. What locale are you using, and what is the decimal separator character supposed to be in your locale?
    - avereveard 5y ago
      https://i.imgur.com/WrsVwFz.png https://i.imgur.com/WrsVwFz.png absolutely standard
      - mwcampbell 5y ago
        It looks like your "Digit grouping symbol" field is empty. I'm sure that's standard in some locales, though not for US English. I don't know how to make that field empty; when I try, Windows says it's invalid. So I wonder if your locale sets that separator to some kind of Unicode character that, in a proper renderer, is equivalent to no character at all. If that's the case, then I'm guessing refterm could handle that character as easily as it handles VT escape codes. But this does lend some weight to the position that Casey was oversimplifying things a bit.
      - maficious 5y ago
        well, whatever is different in your settings, mine renders normal https://imgur.com/dGI5W2S https://imgur.com/dGI5W2S EDIT: I am sorry for the attitude, changed "wrong" to "different"
        mwcampbell 5y ago
        Their settings aren't wrong, just different, likely because of differing standards for digit grouping across locales. So this is a case that refterm clearly doesn't support. This case by itself doesn't invalidate refterm's approach to rendering, but I can see why the team at Microsoft, knowing that there are many such cases, would favor abstraction over the absolute best possible speed.
        avereveard 5y ago
        which is exactly the point.

mwcampbell 5y ago

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

vermilingua 5y ago
This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?
- onion2k 5y ago
  This is exactly the sort of "we can just skip that feature to make it faster!" edge case that I was talking about in my post.
  - vermilingua 5y ago
    But it isn't an edge case! It's not an edge case, if it isn't a use case! This is an edge case as much as building a rasterizer directly into the terminal is an "edge case".
    - l30n4da5 5y ago
      > But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.
      - fouric 5y ago
        Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be". The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts. That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.

deleted 5y ago

[deleted]