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
-
-
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 -
Yeah - the goal of this entire exercise was just to demonstrate that Windows Terminal would get 10x faster if they rendered sensibly, and also they'd get another 10x faster on top of that if they fixed conhost etc. There is probably another 10x on top of that for optimization...
2 replies 0 retweets 3 likes -
Replying to @cmuratori @Tyriar and
... but I didn't optimize my code so I suspect that the two seconds it currently takes for a 1gb file is just my byte-by-byte parser sucking. So at some point I will do more testing to find out how much more headroom there is, but the 100x I showed is almost certainly still low!
1 reply 0 retweets 3 likes -
I agree, someone who works with me on xterm.js focuses hard on throughput so i know there's a lot you can squeeze out there (though we need to deal with JS which has another set of problems).
1 reply 0 retweets 0 likes -
Replying to @Tyriar @cmuratori and
Realistically though the 10x from fastpipe wouldn't be able to be entirely eliminated as I understand it's a fairly complex problem. Additionally it's critical to backwards compatibility of Windows console apps so it has to do things sometimes like rerender the whole screen.
2 replies 0 retweets 0 likes -
But those aren't really very justifications in my opinion. Just put a button in your config that is "no backwards compat", and if you check that, then your terminal runs really fast :)
2 replies 0 retweets 2 likes -
Replying to @cmuratori @Tyriar and
But more specifically, I'm pretty sure even back-compat parsing could probably be done an order of magnitude faster than it's being done now. I can't say for sure but I strongly suspect that code is not high-perf code, if one were to go look.
2 replies 0 retweets 3 likes -
Did you happen to go look at the glyph code they have? This comment says they already use a texture atlas: https://github.com/microsoft/terminal/issues/10362#issuecomment-862852850 …2 replies 0 retweets 0 likes -
_They_ don't use a texture atlas. That comment is talking about the author's supposition that DirectWrite is using a glyph cache. But the problem is that the calls to DirectWrite itself are a major bottleneck, so it is caching on the wrong side of the problem.
1 reply 0 retweets 1 like
The correct architecture is to cache both glyph sizing and glyph imagery. refterm does both. This avoids calling DirectWrite for anything you've seen before, which is the crucial thing you need to do to not be horribly slow, because DirectWrite is awful.
-
-
Replying to @cmuratori @Tyriar and
What I was trying to convey to the Windows Terminal team in that thread was that they can just make a tile renderer themselves so they can't abstract away the slow part of their code. I was unsuccessful.
1 reply 0 retweets 1 like -
Replying to @cmuratori @Tyriar and
As I understand it, the supposition is that DirectWrite caches inside each draw call, so that only helps for each DirectWrite draw call, so it doesn't persist across frames or multiple DWrite calls in one frame, making it a lot less useful
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.