4 ms·

To play devil's advocate, what I see in that demo is that: - Yeah, some lower-level stuff seems to be broken (the windows console I/O stuff). - Microsoft's de

To play devil's advocate, what I see in that demo is that: - Yeah, some lower-level stuff seems to be broken (the windows console I/O stuff). - Microsoft's devs linked to a very nice website that quickly and nicely explains some of the quirks of modern text rendering [1]. - Casey proceeds to demonstrate a (very fast!) approach that completely ignores some of the problems laid out in that site. Namely, his entire approach is based on caching rendered glyphs, which the document explicitly states is something you can't do naively and expect correct results (section 5). - In his very demo some of these issues pop up (terrible-looking emojis, misaligned ascii art) and he shrugs those off as if they were easy jobs. - Other issues are never tested in his demo. Examples include: (i) dealing with text selection, which is hard according to the linked site; (ii) how is he "chunking" non-asscii character runs (also hard to do correctly); (iii) handling ligatures (terminal programs oftentimes use ligatures between basic ascii character combinations such as => to make some source code more readable) In other words: I see an incomplete solution that addresses only the easy parts of the problems (in a very performant way!) that fundamentally cannot be extended to a correct solution for the actual/full problem. And a lot of arrogance while presenting it. In no way does this mean that a much more performant solution doesn't exist. But Casey's cute demo is not a proof that it does because it does not solve the actual/full problem. PS: I don't work for MS, I don't know Casey nor any of MS's devs, and I don't even use windows. I do hold a PhD though, and I know plenty of PhD's dedicated to exploring the nitty-gritty details that some people with only cursory knowledge about the problem would dismiss as "this must be a quick job". [1] https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/

jiggawatts 5y ago
> caching rendered glyphs, which the document explicitly states is something you can't do naively and expect correct results But very slightly less naively you can get correct results. One trick is to realise that ClearType only increases the effective horizontal resolution. Also, despite appearing to have three times the horizontal texels available to it, the final post-processing to reduce the colour artefacts means that the effective resolution increase is only about double the pixel count. So you can get very good results by horizontally stretching your glyph cache buffer by a small factor, typically three. This is not a huge increase in memory usage, and provides more than sufficient subpixel positioning quality. Where this breaks down is if your pipeline has very complex text special effect support, such as arbitrary transforms. But a terminal emulator needs very few special effects. It doesn't need to be rotated smoothly through arbitrary angles, which DirectText supports. It doesn't need perspective transforms, or transparent text, or a whole range of such exotic features. In fact, 99.99% of the characters drawn by a terminal emulator will be plain ASCII aligned to a simple grid. This is a trivial problem to solve, as demonstrated in this thread. It's not PHD work, it's homework.
dmitriid 5y ago
> what I see in that demo is that: Remember: this is a demo written by one person over a few days, and not, you know, a full team of people at a multi-billion-dollar corporation. > Microsoft's devs linked to a very nice website > some of these ... hard according to the linked site ... 1. It's more excuses, and 2. we are not talking about "everything on the website". He took all the constraints that the Windows terminal team imposed (you have to use DirectDraw, you have to go through conio, you have to use the unicode subsystem in Windows), and: - even using those constraints he sped up the terminal 10x - he already does things than windows terminal doesn't, for example: correct Arabic with correct ligatures despite "omg this website shows why it is so hard". So yes, he caches glyphs, and still displays proper Arabic text (something Windows terminal doesn't do) with varying widths etc. And that 10x speedup? Instantly available to Windows terminal if only they use a cache of glyphs instead calling DirectDraw on every character. This is not rocket science. This is not "phd level research thesis". This is just junior-student-level work. As to the issues: - he was the very first one to point them out because he a) knows about them and b) knows how to solve them - yes, the solutions he proposes are easy: the main "issue" is DirectDraw improperly handling font substitution, and his proposed solutions (resample glyphs after draw or skip DirectDraw and write your own glyph renderer) are easy. He literally does that for a living. - omg text selection. Yes, text selection is a hard problem. But it's not an impossible problem, and nothing about text selection should bring the renderer from 5k fps to 2fps > some people with only cursory knowledge about the problem would dismiss as "this must be a quick job" These are not "nitty-gritty" details. And they are definitely not from a "person with cursory knowledge". There's nothing new in terminal rendering.

jiggawatts 5y ago

> caching rendered glyphs, which the document explicitly states is something you can't do naively and expect correct results But very slightly less naively you can get correct results. One trick is to realise that ClearType only increases the effective horizontal resolution. Also, despite appearing to have three times the horizontal texels available to it, the final post-processing to reduce the colour artefacts means that the effective resolution increase is only about double the pixel count. So you can get very good results by horizontally stretching your glyph cache buffer by a small factor, typically three. This is not a huge increase in memory usage, and provides more than sufficient subpixel positioning quality. Where this breaks down is if your pipeline has very complex text special effect support, such as arbitrary transforms. But a terminal emulator needs very few special effects. It doesn't need to be rotated smoothly through arbitrary angles, which DirectText supports. It doesn't need perspective transforms, or transparent text, or a whole range of such exotic features. In fact, 99.99% of the characters drawn by a terminal emulator will be plain ASCII aligned to a simple grid. This is a trivial problem to solve, as demonstrated in this thread. It's not PHD work, it's homework.

dmitriid 5y ago

> what I see in that demo is that: Remember: this is a demo written by one person over a few days, and not, you know, a full team of people at a multi-billion-dollar corporation. > Microsoft's devs linked to a very nice website > some of these ... hard according to the linked site ... 1. It's more excuses, and 2. we are not talking about "everything on the website". He took all the constraints that the Windows terminal team imposed (you have to use DirectDraw, you have to go through conio, you have to use the unicode subsystem in Windows), and: - even using those constraints he sped up the terminal 10x - he already does things than windows terminal doesn't, for example: correct Arabic with correct ligatures despite "omg this website shows why it is so hard". So yes, he caches glyphs, and still displays proper Arabic text (something Windows terminal doesn't do) with varying widths etc. And that 10x speedup? Instantly available to Windows terminal if only they use a cache of glyphs instead calling DirectDraw on every character. This is not rocket science. This is not "phd level research thesis". This is just junior-student-level work. As to the issues: - he was the very first one to point them out because he a) knows about them and b) knows how to solve them - yes, the solutions he proposes are easy: the main "issue" is DirectDraw improperly handling font substitution, and his proposed solutions (resample glyphs after draw or skip DirectDraw and write your own glyph renderer) are easy. He literally does that for a living. - omg text selection. Yes, text selection is a hard problem. But it's not an impossible problem, and nothing about text selection should bring the renderer from 5k fps to 2fps > some people with only cursory knowledge about the problem would dismiss as "this must be a quick job" These are not "nitty-gritty" details. And they are definitely not from a "person with cursory knowledge". There's nothing new in terminal rendering.