In before the torrent of responses such as "no reasonable human being would have a terminal with that many characters!!!"
-
-
Replying to @Jonathan_Blow
You should also get in before the people who - without testing it - will say "use cmder!" (which is _ten times_ slower on this benchmark) or "use alakritty" (which crashes on this benchmark after two frames), etc.
5 replies 1 retweet 32 likes -
Replying to @cmuratori @Jonathan_Blow
Do you have a baseline to compare it to something? Either a fast terminal on a different platform but similar hardware or doing the same render with the deprecated API?
1 reply 0 retweets 0 likes -
Replying to @stephc_int13 @cmuratori
I mean I can just open our Sokoban game console to fullscreen and pick a moderately smaller font and measure how many fps it gets (answer: lots).
1 reply 0 retweets 9 likes -
Replying to @Jonathan_Blow @cmuratori
I don't think this is entirely realistic, even if it can serves to get an idea of the rendering load if correctly implemented with OpenGL.
1 reply 0 retweets 0 likes -
-
Replying to @Jonathan_Blow @cmuratori
Because a terminal emulator is not only a text renderer. I also think that the logic and I/O should be almost free on modern hardware, but it would not be an apple/apple comparison if we don't take the full context into account.
1 reply 0 retweets 0 likes -
Do you honestly think emulating a terminal is more expensive than simulating a 3D game?
1 reply 0 retweets 5 likes -
Absolutely not, I don't think the result of this benchmark is normal. But a benchmark is not very useful if we can't compare to a baseline, and I don't think rendering text is a totally fair baseline. My guess is that what we're seeing is not only a rendering issue.
1 reply 0 retweets 0 likes -
I would assume it is not a rendering issue, actually. It is almost certainly a parsing issue first, and a rendering issue second - ie., the rendering is probably slow, but the parsing of VT codes is almost certainly the bottleneck here.
2 replies 0 retweets 9 likes
(and perhaps I should be more specific - when I say "parsing" is the issue, I really just mean "converting the input into the cell glyphs"... it may not be the parsing specifically that is slow, it could be something done after the parsing but before the rendering, etc.)
-
-
This is probably even worse. GetConsoleScreenBufferInfo is taking 90ms (for a total of ~200ms) when I run the benchmark here.
1 reply 0 retweets 0 likes -
Well sure, but all you know is that it stalled for that long behind that API. It's highly likely that is just reporting the fact that the terminal is busy processing and can't answer you, not that it is actually taking that long to find out how big the console is.
0 replies 0 retweets 1 like
End of conversation
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.