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.
-
-
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 am trying to get you to take off your Microsoft goggles and just look at this from first principles. How many cycles should it take to handle VT100 escape codes in a console?
1 reply 0 retweets 8 likes -
Replying to @Jonathan_Blow @Tyriar and
I am annoyed about this because the kind of stuff you are saying is all I hear from programmers on the internet every day, and the result is that software keeps getting worse and worse, and everyone thinks they are doing great.
1 reply 0 retweets 10 likes -
Replying to @Jonathan_Blow @Tyriar and
Like do you actually have any evidence, or even any vague pre-evidentiary reason to think that doing VT100 escape codes should in principle be slow for N == (number of text characters on a screen)? Or are you just picking that as a reason why the comparison is "unfair"
1 reply 0 retweets 5 likes -
Replying to @Jonathan_Blow @Tyriar and
because that's the first thing available you thought of, and if Casey had implemented VT100 escape codes, you would find some other reason it is "unfair"?
1 reply 0 retweets 5 likes -
He did implement some VT codes, the color demo at the end shows that. What he did not do was run the process through a pseudoterminal which is not native to Windows so it needs to run through the slow an emulation layer which I believe is the real problem here
3 replies 0 retweets 0 likes -
Replying to @Tyriar @Jonathan_Blow and
I'd like us to focus on the actual problem rather than "look at these thousands of frames, omg WT so slow". When conpty is slow, it will cause more frames to be rendered. If conpty is fast, less frames get rendered because everything is done already.
1 reply 0 retweets 0 likes -
[1/2] Hi Daniel. I thought it would be clear from the video, but I ran refterm both ways: with fast pipes off, it's running through conhost, so the entire super-slow Windows part _is running_. So the 10x speedup over Windows Terminal was _with_ super slow conhost.
1 reply 0 retweets 4 likes
[2/2] The _additional_ 10x speed up with fast pipes (for 100x total) is what happens when you bypass conhost. So a simple way to say it would be, Windows Terminal is _both_ extremely slow _and_ conhost is extremely slow, each for about a 10x hit that combine for a 100x hit.
-
-
Thanks for the clarification, I was looking at the code trying to verify that but didn't see any of the conpty APIs being touched. But you mentioned ~22:50 that you should measure how splat looks with VT mode turned on which is what confused me - I don't know what good
1 reply 0 retweets 0 likes -
Replying to @Tyriar @cmuratori and
conpty/conio would do without VT parsing enabled. But anyway to summarize my thoughts: - Yes cache them glyphs - Yes+ make conio faster as it will make the terminal I work on faster
1 reply 0 retweets 0 likes - Show replies
New 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.