terminal

Prevailing reason for the speed of ms code: >I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively. https://github.com/microsoft/terminal/issues/10362

Trivia time! The windows console host (conhost) provides the “UI” for nano server. Even on desktop Windows, it’s built with support for running without a window manager. The rendering engine is named “wddmcon” and it lives in our repository at [1]; it’s pretty much the most barebones console renderer we have. Reverse video and most color support were obviously[2] never implemented… even though I would have liked to spend engineering effort on it. The decision predates me, but I suspect it’s because they weren’t necessary for local validation. Wddmcon eventually evolved into the rendering engine used in Windows Terminal[3]; it’s still not very good[4], but it works in conhost as well. Eventually, we can bring those changes or whatever future rendering engine we write back to wddmcon. It has a sister renderer, “bgfxcon”. Bgfxcon renders te

However, if you install Windows Terminal you will find that Start menu behavior changes in a annoying way that the Terminal developers can’t fix without changes to Windows itself[0]. With Terminal installed, if you search for a directory from the Start menu — hit the Windows key, start typing, press enter — the menu won’t close automatically. 0: https://github.com/microsoft/terminal/issues/7122

Apparently not just Microsoft. Quoting from TFA <https://github.com/microsoft/terminal/issues/10362#issuecomm...> skyline75489 commented on Jun 8 Here’s something interesting. I tried to port the benchmark to Linux and I’m seeing a even larger performance gap between colored and non-colored text on Linux (roughly 60x - 80x). The overall rendering performance is better on Windows, of course.

> unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen... The issue may be in your code. I think I have similar performance issues, as the glyph selection process could be more optimized. Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality. Reducing the set of glyph to something that could benefit from optimizations could help. > I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses) Sixel performance is quite decent: personally, I can play videos in m

Some people prefer to communicate with less words? This is an issue that crops up often with different cultures working on a single issue. As for difficult, the context is very much set from it being a Github Issue on their own repo, meaning there is a certain assumption of skill. You're cutting Microsoft a lot of slack here, and it feels like you're forgetting that out of this whole transaction MS end up with free labour and bug-fixes? They choose for the setting to be very public, and they choose to let their employee's directly reply to customers with quotes like[1]: ["I will take your terse response as accepting the summary.", "somewhat combatively", "peppering your comments with clauses like", "impugning the reader."]. All of which are corporate-passive-aggression and (in my mind) are vastly more antagonistic than Casey ever was? 1.

Screen reader support[0] may have a noticeable performance cost. [0] https://github.com/microsoft/terminal/issues/10528#issuecomm...

> Look at the github repo. There are only three committers to Casey's repo. I'm sure Microsoft could manage to contact them. Microsoft's attitude towards the code seems a little odd. [0] Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links. Given that WSL exists I can't imagine this is a universal policy towards reading GPLv2 code at Microsoft. [0] https://github.com/microsoft/terminal/issues/10462#issuecomm...

It's here: https://github.com/cmuratori/refterm That issue was closed but the current open issue which acknowledges this is a real problem is here: https://github.com/microsoft/terminal/issues/10462 Here is a comment on the code directly from a contributor at Microsoft: > @AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us to strive for. Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links. > I‘m the person who‘s tasked with building an equivalent solution and you may subscribe to #10461 to get updates of my progress. Unfortunately our existing project isn’t straight forward to modify the same way we could build a terminal from scratch. A lot

So the comment that the 'PhD' reference was responding to was Muratori laying out how he figured a simple terminal renderer could be implemented, using two texture lookups in a single drawcall [0]. In the course of that, Muratori allowed, almost in passing, that of course you would need, in order to do that: > a glyph atlas encoding the cell-glyph coverage in whatever way makes it easiest to compute your ClearType blending values Now, it does not strike me as beyond the realm of possibility that that step might be suitable for academic research. It calls for an efficient encoding of cleartype-ready glyph data with comprehensive coverage of unicode glyph space (not codepoint space). That's not trivial, and - as the DHowett reply suggests - it would take a literature review to determine if someone has already accomplished this (and he also

And see, even you've done it here. Command Prompt is `cmd.exe`, which is different from PowerShell (`powershell.exe`), and both of those are different still from `conhost.exe`, which is the actual console window itself. cmd and powershell are "shells", which both need to run in a console, and conhost.exe is that console (which is the "terminal window" for these applications). More reading: https://github.com/microsoft/terminal/blob/main/doc/Niksa.md... Conhost is the window that's had updates all throughout Windows 10. It's responsible for both the console subsystem, and the console UI. The UI though is the part that's largely being replaced by the Terminal. Conhost will never go away, but the Terminal is where all the action is these days. (It's also shipping with Windows 11 by default)

That's probably some combo of: * https://github.com/microsoft/terminal/issues/649#issuecommen... * https://github.com/microsoft/terminal/issues/11230#issuecomm...

Possibly the thread has been edited, but I see the original poster claiming that, and it seems a popular view around here, but I don't actually see the evidence that it actually happened in the thread itself. Are we talking about this thread? https://github.com/microsoft/terminal/issues/10362

Maybe, yeah. I don't have everything ready at hand but maybe take a look at: https://github.com/microsoft/terminal/releases/tag/v1.11.242... (Latest release, check the PRs linked under performance) https://github.com/microsoft/terminal/issues/10461 (Issue discussing rendering from a glyph atlas) https://github.com/microsoft/terminal/issues/10462 (This is where one of the contributors quit) https://github.com/microsoft/terminal/issues/10623 (Bullying example)