1/ Interesting video!
I wasn't involved in the issue you mentioned but I use conpty in @code which is what WT uses. You have focused very strongly on rendering speed but is that actually the slow part of WT? I suspect the slowest part is not actually the rendering but the
-
-
/2 speed of the pty emulation (conpty) and the parsing of the excess output that it generates. That's the reason the
@code terminal on Windows is a lot slower than on Linux and macOS. A better comparison would probably be to use WSL bash in WT as I believe that bypasses most of1 reply 0 retweets 4 likes -
/3 what conpty does. Right now running vim, nano, etc. wouldn't work in refterm since you're bypassing this complex Console API<->Pseudoterminal emulation which is the reason these pty-based terminals exist on Windows at all.
1 reply 0 retweets 5 likes -
/4 I just finished the last part of the video about the colors, the glyphs should absolutely be cached and it's surprising to hear that it's not doing that
2 replies 0 retweets 2 likes -
Do you realize that you are just typing excuses of the exact kind he calls out in the video?
1 reply 0 retweets 10 likes -
No, I'm pointing out it doesn't seem to be an entirely fair comparison and agreeing that it's silly not to cache the glyphs. Not here to argue mate, would be great it WT or conpty could get faster as a result of this.
2 replies 0 retweets 2 likes -
Did you skip over like half the video, then?
1 reply 0 retweets 5 likes -
No, did you read my tweets? The emulation is likely the slowest part of Windows Terminal, not the rendering, especially if there's a dedicated render thread. It's why the terminal I maintain is much slower on Windows. Refterm didn't include that emulation.
1 reply 0 retweets 4 likes -
Sorry, I am just seeing excuses. Why do you think a 4GHz computer from 2021 should have trouble with VT100 escape codes from 1978?
1 reply 0 retweets 10 likes -
I agree with you, and I enjoy your talks on the topic and know you care and are frustrated by the state of performance in software. Once again I agreed with the main issue that the glyphs should be cached. But that doesn't make it not an unfair comparison.
3 replies 0 retweets 2 likes
I strongly object to your saying this is an "unfair comparison". The non-fast-pipe versions, that were all 10x faster in the demo as I showed, all ran through conhost! What are you talking about?
-
-
This Tweet is unavailable.
-
Replying to @MurrFurryNet @Tyriar and
That seems unnecessarily harsh. xterm.js is at least an attempt to have faster terminal support in JS. You can argue that JS is bad to begin with, but a lot of people use it anyway, so you can't fault people for trying to make utilities for it.
0 replies 0 retweets 3 likes
End of conversation
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.