Extremely slow performance when processing virtual terminal sequences #14269

@CoreyDotCom commented on GitHub (Jun 19, 2021):

Note that this is a clone of https://github.com/microsoft/terminal/issues/10362 which was closed by original submitter. As the original bug report was valid it should have been remained open, especially after quite a few suggestions were provided as to how to improve matters. Feel free to reopen original tracking issue and close this duplicate if appropriate. Thank you for the work that you guys do on this project.

@CoreyDotCom commented on GitHub (Jun 19, 2021): Note that this is a clone of https://github.com/microsoft/terminal/issues/10362 which was closed by original submitter. As the original bug report was valid it should have been remained open, especially after quite a few suggestions were provided as to how to improve matters. Feel free to reopen original tracking issue and close this duplicate if appropriate. Thank you for the work that you guys do on this project.

claunia commented

@DHowett commented on GitHub (Jun 19, 2021):

Thanks for re-opening this! It’s definitely valuable for us to be tracking it, and the ideas suggested in the original thread are good ones that are worth considering. We also have #10461 tracking specific requests from #10362.

@DHowett commented on GitHub (Jun 19, 2021): Thanks for re-opening this! It’s definitely valuable for us to be tracking it, and the ideas suggested in the original thread are good ones that are worth considering. We also have #10461 tracking specific requests from #10362.

claunia commented

@lhecker commented on GitHub (Jun 19, 2021):

Personally I'd like to also welcome @cmuratori and @mmozeiko back to give any comments if they wish to do so. Of course it'd be entirely understandable if they don't. I believe I can speak for the terminal team, when I say that we want to keep the door to our community open and welcome any civil discourse.

I see the comment regarding slow VT parsing again, but I hope you consider that performance of OpenConsole (aka future conhost) has already improved about 4-5x in the last year. With upcoming conhost versions, or the current OpenConsole, you can expect to see a throughput improvement from 4MB/s to about 16-20MB/s for termbench. I know this isn't 270MB/s, but it's a significant improvement regardless, despite keeping all the backwards-compatibility, etc.

For instance - referring to the mentioned offenders:

ATTR_ROW::InsertAttrRuns was entirely rewritten and doesn't allocate std::vectors anymore in Certain pane zoom operations make the terminal go blank (#10099)
_ViewportToString doesn't even exist anymore and was replaced in #5024

We're now working on improving _SetGraphicsRenditionRGBColor in #10426, which will improve performance for termbench by another 20-25%. FYI: @skyline75489 is working on this entirely in their spare time! (...and the PR is in fact not finished yet. It'll likely feature more improvements once it's done.)

Here's a flamegraph of OpenConsole for termbench:

The render output thread is highlighted in blue. _SetGraphicsRenditionRGBColor is being hovered.

If you have concrete ideas what to improve (and optionally how) to speed up OpenConsole's VT performance further, please let us know and we'll get to it. Promise! Contributions are especially welcome at any time!

@lhecker commented on GitHub (Jun 19, 2021): Personally I'd like to also welcome @cmuratori and @mmozeiko back to give any comments if they wish to do so. Of course it'd be entirely understandable if they don't. I believe I can speak for the terminal team, when I say that we want to keep the door to our community open and welcome any civil discourse. --- I see the comment regarding slow VT parsing again, but I hope you consider that performance of OpenConsole (aka future conhost) has already improved about 4-5x in the last year. With upcoming conhost versions, or the current OpenConsole, you can expect to see a throughput improvement from 4MB/s to about 16-20MB/s for termbench. I know this isn't 270MB/s, but it's a significant improvement regardless, despite keeping all the backwards-compatibility, etc. For instance - referring to the mentioned offenders: * `ATTR_ROW::InsertAttrRuns` was entirely rewritten and doesn't allocate `std::vector`s anymore in #10099 * `_ViewportToString` doesn't even exist anymore and was replaced in #5024 We're now working on improving `_SetGraphicsRenditionRGBColor` in #10426, which will improve performance for termbench by another 20-25%. FYI: @skyline75489 is working on this entirely in their spare time! (...and the PR is in fact not finished yet. It'll likely feature more improvements once it's done.) Here's a flamegraph of OpenConsole for termbench: ![openconsole_termbench_flamegraph](https://user-images.githubusercontent.com/2256941/122650776-08709580-d135-11eb-9d93-6e11581ae45e.png) The render output thread is highlighted in blue. `_SetGraphicsRenditionRGBColor` is being hovered. If you have concrete ideas what to improve (and optionally how) to speed up OpenConsole's VT performance further, please let us know and we'll get to it. Promise! Contributions are especially welcome at any time!

claunia commented

@mmozeiko commented on GitHub (Jun 19, 2021):

Is there a possibility we (outside of Microsoft) can get some documentation or specification on console driver interface -\\Device\\ConDrv\\Server, structures in condrv.h and conmsgl*.h files ?

@mmozeiko commented on GitHub (Jun 19, 2021): Is there a possibility we (outside of Microsoft) can get some documentation or specification on console driver interface -`\\Device\\ConDrv\\Server`, structures in `condrv.h` and `conmsgl*.h` files ?

claunia commented

2026-01-31 04:05:40 +00:00

@DHowett commented on GitHub (Jun 19, 2021):

Fair question! We should definitely have some docs on the driver interface, since we're now an open source project that is using an underdocumented OS fixture...

Right now the best we have is in the ApiDispatcher and some of the "load bearing code" comments across the codebase. That's not great. I'll see what we can do about that!

@DHowett commented on GitHub (Jun 19, 2021): Fair question! We should definitely have some docs on the driver interface, since we're now an open source project that is using an underdocumented OS fixture... Right now the best we have is in the ApiDispatcher and some of the "load bearing code" comments across the codebase. That's not great. I'll see what we can do about that!

claunia commented

@lhecker commented on GitHub (Jun 19, 2021):

@mmozeiko Sure! Let's continue that discussion here: #10463

@lhecker commented on GitHub (Jun 19, 2021): @mmozeiko Sure! Let's continue that discussion here: #10463

claunia commented

2026-01-31 04:05:40 +00:00

@skyline75489 commented on GitHub (Jun 26, 2021):

I'm hiding this comment because some people find it dismissive and feel that I'm finding excuses. I'm honestly just trying to find the truth.

Thanks @CoreyDotCom for the interest in this particular issue. After days of researching & testing, I think I've come to a conclusion that I would like to share with everyone.

I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x.

This is sadly not the truth at the moment. I've tested a bunch of terminals, including GNOME Terminal, rxvt, tilix and Alacritty (perhaps the fastest terminal emulator for the moment being), they both show significant performance drop with heavy VT load. See https://github.com/alacritty/alacritty/issues/5278 for details. The maintainer of Alacritty seems to concur with this conclusion: the performance drop with massive VT load is reasonable & expected.

I haven't got the chance to test terminals on macOS, because I feel iTerm2 is not really a terminal that focuses on performance (but on great functionalities). Please let me know if there's any terminal out there (whatever the platform) that's worth trying and I can take a look.

especially after quite a few suggestions were provided as to how to improve matters.

One of the suggestions has landed in #10426, but the performance improvement is not as impressive as mentioned in the original issue(3x), because the original code is flawed in a way that bypasses the worst case. The actual saving of CPU is ~8%.

Another suggestion regarding switching to glyph atlas approach is tracked in #10461. Do notice that Alacritty is already using similar approach as in glyph atlas. So the VT load might still be the bottleneck, even if we finished #10461. CC @lhecker to verify this.

@skyline75489 commented on GitHub (Jun 26, 2021): I'm hiding this comment because some people find it dismissive and feel that I'm finding excuses. I'm honestly just trying to find the truth. <details> Thanks @CoreyDotCom for the interest in this particular issue. After days of researching & testing, I think I've come to a conclusion that I would like to share with everyone. > I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x. This is sadly not the truth at the moment. I've tested a bunch of terminals, including GNOME Terminal, rxvt, tilix and Alacritty (perhaps the fastest terminal emulator for the moment being), they both show significant performance drop with heavy VT load. See https://github.com/alacritty/alacritty/issues/5278 for details. The maintainer of Alacritty seems to concur with this conclusion: the performance drop with massive VT load is reasonable & expected. I haven't got the chance to test terminals on macOS, because I feel iTerm2 is not really a terminal that focuses on performance (but on great functionalities). Please let me know if there's any terminal out there (whatever the platform) that's worth trying and I can take a look. --- >especially after quite a few suggestions were provided as to how to improve matters. One of the suggestions has landed in #10426, but the performance improvement is not as impressive as mentioned in the original issue(3x), because the original code is flawed in a way that bypasses the worst case. The actual saving of CPU is ~8%. Another suggestion regarding switching to glyph atlas approach is tracked in #10461. Do notice that Alacritty is already using similar approach as in glyph atlas. So the VT load might still be the bottleneck, even if we finished #10461. CC @lhecker to verify this. </details>

claunia commented

2026-01-31 04:05:40 +00:00

@skyline75489 commented on GitHub (Jun 26, 2021):

I'm hiding this comment because some people find it dismissive and factually incorrect.

To answer more questions in the original issue (#10362) and a reasonable amount of insult & sarcasm towards me on Twitter:

Modern AAA games can render millions of polygons and do ray-traced lighting at 60 fps

Modern AAA games also use up to all of CPU cores (with up to 100% load) and almost all of the GPU memory & computing power at its disposal. People don't really expect this kind of resource usage from a terminal application. One of the key goal of the terminal is I believe to minimize the resource usage.

I may sound innocent but I don’t actually know a AAA game that draws millions of text. The only kind of applications that ( I know of) draw a lot of text is terminal applications.

There's of course many applications that's capable of drawing text, including browsers & word processors. But the uniqueness of the terminal is the way people sometimes use it for lots of changing text. Take termbench as an extreme example, it generates an entire window of changing characters, with changes happen in the content, the color & the background. If we actually use browser tech to handle this kind of workload, for example in Hyper, the result on my computer is not that ideal, either.

I'm not trying to diss Hyper of other similar products. Just want to clarity that browser can handle very complicated text layout smoothly, in a way that terminal can possibly never do. But at the same time, terminal never intend to be capable of handling the same amount of layout issues as browsers or Microsoft Word, because there's no practical meaning in it. Different type of applications, different type of workload. Everyone is happy.

if Windows console infrastructure is not (and has never been) performant, then you do not know what daily-usage applications you are missing, which are impossible to write currently due to the pervasive slowness.

The Windows console infrastructure will be improved as each Windows release. But the release cycle of Windows is complicated & slow. Majority of the complains in #10362 are related to a much older version of cmd.exe than we currently have in this repo. The latest version of OpenConsole will ship with Windows Terminal. If people are using Windows Terminal, I think the "daily-usage applications" part should be fine.

After all being said, I found most of the comments in #10362 valuable & meaningful. But I found no vicious tweet that provides helpful information.

@skyline75489 commented on GitHub (Jun 26, 2021): I'm hiding this comment because some people find it dismissive and factually incorrect. <details> To answer more questions in the original issue (#10362) and a reasonable amount of insult & sarcasm towards me on Twitter: > Modern AAA games can render millions of polygons and do ray-traced lighting at 60 fps Modern AAA games also use up to all of CPU cores (with up to 100% load) and almost all of the GPU memory & computing power at its disposal. People don't really expect this kind of resource usage from a terminal application. One of the key goal of the terminal is I believe to minimize the resource usage. --- > I may sound innocent but I don’t actually know a AAA game that draws millions of text. The only kind of applications that ( I know of) draw a lot of text is terminal applications. There's of course many applications that's capable of drawing text, including browsers & word processors. But the uniqueness of the terminal is the way people sometimes use it for lots of **changing** text. Take termbench as an extreme example, it generates an entire window of changing characters, with changes happen in the content, the color & the background. If we actually use browser tech to handle this kind of workload, for example in Hyper, the result on my computer is not that ideal, either. I'm not trying to diss Hyper of other similar products. Just want to clarity that browser can handle very complicated text layout smoothly, in a way that terminal can possibly never do. But at the same time, terminal never intend to be capable of handling the same amount of layout issues as browsers or Microsoft Word, because there's no practical meaning in it. Different type of applications, different type of workload. Everyone is happy. --- > if Windows console infrastructure is not (and has never been) performant, then you do not know what daily-usage applications you are missing, which are impossible to write currently due to the pervasive slowness. The Windows console infrastructure will be improved as each Windows release. But the release cycle of Windows is complicated & slow. Majority of the complains in #10362 are related to a much older version of `cmd.exe` than we currently have in this repo. The latest version of `OpenConsole` will ship with Windows Terminal. If people are using Windows Terminal, I think the "daily-usage applications" part should be fine. --- After all being said, I found most of the comments in #10362 valuable & meaningful. But I found no vicious tweet that provides helpful information. </details>

claunia commented

@mmozeiko commented on GitHub (Jun 26, 2021):

Modern AAA games also use up to all of CPU cores (with up to 100% load) and almost all of the GPU memory & computing power at its disposal. People don't really expect this kind of resource usage from a terminal application. One of the key goal of the terminal is I believe to minimize the resource usage.

What kind of argument is this?!? You are completely missing the point. Are you saying it is unfair to compare to AAA game because terminal should or cannot use same kind of power/load? If answer is yes - then this project is failing. Because it is doing exactly that - using 100% of same load/power as AAA game, but doing far simpler rendering. In fact it is actually using more - here's comparison running Overwatch.exe vs WindowsTerminal.exe with termbench: https://i.imgur.com/7VVWh9W.png who is using more cpu? As far as I can tell: 3.22+1.03 > 1.19

Obviously terminal should not use 100% load of cpu core or gpu to render fullscreen of text. I have demonstrated that with real code (1000+fps rendering) which Casey also was explaining. Limit it to composition rate, and you'll have mostly idle cpu core.

And yes, sure the other part of code - actual layout of characters will take extra time. But doing that in fixed monospaced grid is far from complexity of text layout in browsers or word processors that you and others like to mention a lot. Like really really far away, super far away. Having extra constraints like that makes problem much simpler. Which Casey is working on, and in current state it can do much of unicode and still runs in sub-millisecond per frame (not completely finished, but there's no doubt it'll work with same kind of performance).

I may be saying things a bit out of line here - but if you don't know how hard (or easy) is to do text layout for unicode, then you should simply say that. Instead of claiming it is hard (because you don't know that). For example, I don't know that, because I've never done full-blown unicode rendering or looked into details. But I trust other people / expert opinion who have done it, and they say it is completely doable in this situation.

But the uniqueness of the terminal is the way people sometimes use it for lots of changing text.

This sentence makes me upset way more than anything that was said before. Do you understand that any simple (not "modern AAA game") is outputting more than 2 MILLION pixels (on 1080p screen) that changes EVERY single frame and each of them can have UNIQUE color. That is more than 120 MILLION unique pixels per second. But here we are again still discussing why outputting something like 30 thousand of text characters difficult or unique...

@mmozeiko commented on GitHub (Jun 26, 2021): > Modern AAA games also use up to all of CPU cores (with up to 100% load) and almost all of the GPU memory & computing power at its disposal. People don't really expect this kind of resource usage from a terminal application. One of the key goal of the terminal is I believe to minimize the resource usage. What kind of argument is this?!? You are completely missing the point. Are you saying it is unfair to compare to AAA game because terminal should or cannot use same kind of power/load? If answer is yes - then this project is failing. Because it is doing exactly that - using 100% of same load/power as AAA game, but doing far simpler rendering. In fact it is actually using more - here's comparison running Overwatch.exe vs WindowsTerminal.exe with termbench: https://i.imgur.com/7VVWh9W.png who is using more cpu? As far as I can tell: `3.22+1.03 > 1.19` Obviously terminal should not use 100% load of cpu core or gpu to render fullscreen of text. I have demonstrated that with real code (1000+fps rendering) which Casey also was explaining. Limit it to composition rate, and you'll have mostly idle cpu core. And yes, sure the other part of code - actual layout of characters will take extra time. But doing that in fixed monospaced grid is far from complexity of text layout in browsers or word processors that you and others like to mention a lot. Like really really far away, super far away. Having extra constraints like that makes problem much simpler. Which Casey is working on, and in current state it can do much of unicode and still runs in sub-millisecond per frame (not completely finished, but there's no doubt it'll work with same kind of performance). I may be saying things a bit out of line here - but if you don't know how hard (or easy) is to do text layout for unicode, then you should simply say that. Instead of claiming it is hard (because you don't know that). For example, I don't know that, because I've never done full-blown unicode rendering or looked into details. But I trust other people / expert opinion who have done it, and they say it is completely doable in this situation. > But the uniqueness of the terminal is the way people sometimes use it for lots of changing text. This sentence makes me upset way more than anything that was said before. Do you understand that any simple (not "modern AAA game") is outputting more than 2 MILLION pixels (on 1080p screen) that changes EVERY single frame and each of them can have UNIQUE color. That is more than 120 MILLION unique pixels per second. But here we are again still discussing why outputting something like 30 thousand of text characters difficult or unique...

claunia commented

@skyline75489 commented on GitHub (Jun 26, 2021):

I'm hiding this comment because it does not contain useful information for most people.

> Are you saying it is unfair to compare to AAA game because terminal should or cannot use same kind of power/load? If answer is yes - then this project is failing

Yea I am suggesting that. Because it’s my honest opinion. If the project is failing because of this, I am actually OK with it. I don’t work for this team. I don’t get paid for this. I am doing this because I love to contribute to this project. I am only an outside contributor.

Instead of claiming it is hard (because you don't know that).

I admitted my mistake in #10461 about wrongly claiming text rendering is hard. I made faulty assumptions and I am not proud of it.

But the uniqueness of the terminal is the way people sometimes use it for lots of changing text

I am comparing the terminal with browsers & word processor, which all are text-oriented. My idea is simple, different types of applications, different workloads. So I’m not trying to compare the terminal with games. I gave an example in Hyper, which uses browser technology to render a terminal. I’d be more than happy to see the equivalent in modern games. I really mean this.

@mmozeiko i respect your knowledge in gaming development, which i have none. My idea could be wrong. And if my opinion is biased or wrong, I am glad to be corrected. If any of my words offended your personally, please let me know. I am kindly asking you to keep this discussion calm, civil & technical.

@skyline75489 commented on GitHub (Jun 26, 2021): I'm hiding this comment because it does not contain useful information for most people. <details> > Are you saying it is unfair to compare to AAA game because terminal should or cannot use same kind of power/load? If answer is yes - then this project is failing Yea I am suggesting that. Because it’s my honest opinion. If the project is failing because of this, I am actually OK with it. I don’t work for this team. I don’t get paid for this. I am doing this because I love to contribute to this project. I am only an outside contributor. > Instead of claiming it is hard (because you don't know that). I admitted my mistake in #10461 about wrongly claiming text rendering is hard. I made faulty assumptions and I am not proud of it. > But the uniqueness of the terminal is the way people sometimes use it for lots of changing text I am comparing the terminal with browsers & word processor, which all are text-oriented. My idea is simple, different types of applications, different workloads. So I’m not trying to compare the terminal with games. I gave an example in Hyper, which uses browser technology to render a terminal. I’d be more than happy to see the equivalent in modern games. I really mean this. @mmozeiko i respect your knowledge in gaming development, which i have none. My idea could be wrong. And if my opinion is biased or wrong, I am glad to be corrected. If any of my words offended your personally, please let me know. I am kindly asking you to keep this discussion calm, civil & technical. </details>

claunia commented

@lhecker commented on GitHub (Jun 26, 2021):

@skyline75489 @mmozeiko I've already built a prototype for unicode text rendering using a glyph atlas. I'm currently working on integrating it into our existing code in whatever time I can spare. The performance you get out of it is extremely impressive.
I'm doubtful that the comparison with Overwatch is anywhere near fair, especially if you showed a couple more columns there. But regardless, you certainly won't have to convince me to build it that way anymore, as I've been determined to build it that way for quite a while now.
All of this is and will be tracked #10461. And again I should mention that this isn't just to be considered, it's in fact on the backlog.

A performance drop of ~40x from maximum theoretical framerate, when drawing colored output using termbench, should always be considered expected, as termbench outputs about ~40x as much text, when coloring is enabled. I'm not saying we can't be even better than that, but it's logical that a drop like that should at least, in the most literal sense, be expected. I think it's loosely approximately the same drop in other terminals. We'll now just make sure that we don't drop the framerate below anything in the hundreds (or thousands?), because that's definitely something other terminals don't do.

Either way I feel like this discussion is starting to heat up again.
I'd like to note a couple things:

We have people with vastly different languages, cultures and experiences here, and things you read might not always be the exact tone that the author intended to write it in. Additionally, due to the difference in experience, statements that you read here should obviously not be read as facts. They can be discussed however you want, but you don't have to assume that everyone immediately shares anybody's opinion, even if they happen to be objectively right.
To anyone else reading this (basically Twitter): Please refrain from saying that certain people in this issue "live in caves" and other, even significantly harsher, things over this again. Some people might not like that very much and block up instead of trying to be understanding.
But most importantly, the discussion why drawing 30k characters is difficult won't be reopened, because we already agreed that we can significantly simplify it. Especially not in this issue. Dustin and me have already excused ourselves for our uncordial comments and will implement a faster renderer that doesn't have this issue.

Anyways, as I said before, you won't have to convince me of it, the person who'll actually build it. I'm already convinced.
Instead this issue will be exclusively about VT performance and I'd like to exclusively see:

Discussion about VT/ConPTY performance
Suggestions for improving said performance

@lhecker commented on GitHub (Jun 26, 2021): @skyline75489 @mmozeiko I've already built a prototype for unicode text rendering using a glyph atlas. I'm currently working on integrating it into our existing code in whatever time I can spare. The performance you get out of it is extremely impressive. I'm doubtful that the comparison with Overwatch is anywhere near fair, especially if you showed a couple more columns there. But regardless, you certainly won't have to convince me to build it that way anymore, as I've been determined to build it that way for quite a while now. All of this is and will be tracked #10461. And again I should mention that this isn't just to be considered, it's in fact on the backlog. A performance drop of ~40x from maximum theoretical framerate, when drawing colored output using termbench, should always be considered expected, as termbench outputs about ~40x as much text, when coloring is enabled. I'm not saying we can't be even better than that, but it's logical that a drop like that should at least, in the most literal sense, be _expected_. I think it's loosely approximately the same drop in other terminals. We'll now just make sure that we don't drop the framerate below anything in the hundreds (or thousands?), because that's definitely something other terminals don't do. Either way I feel like this discussion is starting to heat up again. I'd like to note a couple things: * We have people with _vastly_ different languages, cultures and experiences here, and things you read might not always be the exact tone that the author intended to write it in. Additionally, due to the difference in experience, statements that you read here should obviously not be read as facts. They can be discussed however you want, but you don't have to assume that everyone immediately shares anybody's opinion, _even if they happen to be objectively right_. * To anyone else reading this (basically Twitter): Please refrain from saying that certain people in this issue "live in caves" and other, even significantly harsher, things over this again. Some people might not like that very much and block up instead of trying to be understanding. * But **most importantly**, the discussion why drawing 30k characters is difficult _won't be reopened_, because we already agreed that we can significantly simplify it. Especially not in this issue. Dustin and me have already excused ourselves for our uncordial comments and will implement a faster renderer that doesn't have this issue. Anyways, as I said before, you won't have to convince me of it, the person who'll actually build it. I'm already convinced. Instead _this_ issue will be exclusively about VT performance and I'd like to exclusively see: * Discussion about VT/ConPTY performance * Suggestions for improving said performance

claunia commented

@nico-abram commented on GitHub (Jun 26, 2021):

This is sadly not the truth at the moment. I've tested a bunch of terminals, including GNOME Terminal, rxvt, tilix and Alacritty (perhaps the fastest terminal emulator for the moment being), they both show significant performance drop with heavy VT load. See alacritty/alacritty#5278 for details. The maintainer of Alacritty seems to concur with this conclusion: the performance drop with massive VT load is reasonable & expected.

To be clear: You are saying this can be the case for just the rendering part, but that it can be slower because of VT processing (Which as I understand it, happens mostly in conhost)?

Also, is it possible Alacritty (And all the other terminals you may have tried on windows) are being slowed down by an older version of conhost and slower processing of VT sequences in it than the current OpenConsole? (Possibly making it an unfair comparison)

@nico-abram commented on GitHub (Jun 26, 2021): > This is sadly not the truth at the moment. I've tested a bunch of terminals, including GNOME Terminal, rxvt, tilix and Alacritty (perhaps the fastest terminal emulator for the moment being), they both show significant performance drop with heavy VT load. See alacritty/alacritty#5278 for details. The maintainer of Alacritty seems to concur with this conclusion: the performance drop with massive VT load is reasonable & expected. To be clear: You are saying this *can* be the case for just the rendering part, but that it can be slower because of VT processing (Which as I understand it, happens mostly in conhost)? Also, is it possible Alacritty (And all the other terminals you may have tried on windows) are being slowed down by an older version of conhost and slower processing of VT sequences in it than the current OpenConsole? (Possibly making it an unfair comparison)

claunia commented

@skyline75489 commented on GitHub (Jun 26, 2021):

@Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine.

Which as I understand it, happens mostly in conhost

This is not correct. I think you don’t quite know the full picture of ConPTY. VT processing happens in both conhost & Windows Terminal. This is also true with other terminals on Windows that uses ConPTY. If I have to guess the ratio, I’d probably say 60% in conhost and 40% in the terminal? Just a rough guess. Not precise numbers.

@skyline75489 commented on GitHub (Jun 26, 2021): @Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine. > Which as I understand it, happens mostly in conhost This is not correct. I think you don’t quite know the full picture of ConPTY. VT processing happens in both conhost & Windows Terminal. This is also true with other terminals on Windows that uses ConPTY. If I have to guess the ratio, I’d probably say 60% in conhost and 40% in the terminal? Just a rough guess. Not precise numbers.

claunia commented

@Nicholas-Baron commented on GitHub (Jun 26, 2021):

@Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine.

@skyline75489, I think you have the wrong person.

@Nicholas-Baron commented on GitHub (Jun 26, 2021): > @Nicholas-Baron I don’t quite get it what you are asking. I was testing those Linux terminals on barebone Linux machine. @skyline75489, I think you have the wrong person.

claunia commented

@skyline75489 commented on GitHub (Jun 26, 2021):

Yep sorry. On my phone 😅. @nico-abram

@skyline75489 commented on GitHub (Jun 26, 2021): Yep sorry. On my phone 😅. @nico-abram

claunia commented

https://github.com/cmuratori/refterm

@AnuthaDev commented on GitHub (Jul 4, 2021):

So, this might be of interest:

https://youtu.be/hxM8QmyZXtg

@AnuthaDev commented on GitHub (Jul 4, 2021): So, this might be of interest: https://github.com/cmuratori/refterm https://youtu.be/hxM8QmyZXtg

claunia commented