starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-04-17 11:41:04 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

redraw of scrolling text under WSL, inside GNU screen w/ caption, is way slow #503

New Issue
Closed
opened 2026-01-30 21:53:53 +00:00 by claunia · 13 comments
claunia commented 2026-01-30 21:53:53 +00:00
Owner
Copy Link

Originally created by @aleks-mariusz on GitHub (Jan 4, 2019).

Originally assigned to: @miniksa on GitHub.

repasting details from here:

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

Please fill out the below information:
Version 1809 (OS Build 17763.195)

  • Summary
    I updated to win10 ver 1809 today (previously ran 1803 without issue), and one of the first things i noticed is that when within using GNU screen the redraw is noticeably slower, when using caption value in .screenrc.

  • Environment
    Here's the contents of an example $HOME/.screenrc:

caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'

This is a pretty basic setting for screen to draw a floating "status bar" on the bottom showing what screen is selected, and is discussed on https://lizdenys.com/journal/articles/understanding-gnu-screens-captions.html

Only after i updated to 1809, i noticed that when launching GNU screen from within WSL (triggered via bash.exe), and doing something that requires the screen to re-draw scrolling text, the refresh rate is pretty slow (e.g. doing something like ls -l /usr/bin takes several seconds instead of being near instance when not using that setting in screen.

I've also tried resetting my environment entirely (wiping out all bash shell settings files e.g. $HOME/.bashrc and $HOME/.bash_profile). I narrowed it down to that captions always line being the culprit. I was first noticed how painful running ps auxwww was on a remote linux system :-(

  • What you're doing and what's happening:
    generating output that exceeds the size of the window, resulting in scrolling behaviour. the redraw of the text from scrolling, results in a rate that makes me think i'm back on my first 486 computer
$ echo "caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'" > .screenrc
$ screen
[... inside new screen ...]
$ ls -l /usr/bin
  • What's wrong / what should be happening instead:
    time to perform a simple "dir" (via ls -l /usr/bin) takes ~20 seconds inside GNU screen

this same listing takes only a second and a half when not using GNU screen at all (or not using that captions always line in $HOME/.screenrc) .

whether or not using a screen multiplexer like GNU screen should not affect the refresh time, at least it didn't before i upgraded to win10 ver 1809 today.

  • Strace of the failing command, if applicable:
    not applicable, running the ls comand using time reports nearly identical values:

outside of screen:

real    0m1.240s
user    0m0.016s
sys     0m0.063s

inside screen:

real    0m0.069s
user    0m0.000s
sys     0m0.063s

Which makes it seem that the comand isn't what's running any slower (in fact it reports it ran faster?) but the drawing the scrolling text is what's in-fact impacted.

Originally created by @aleks-mariusz on GitHub (Jan 4, 2019). Originally assigned to: @miniksa on GitHub. repasting details from [here](https://github.com/Microsoft/WSL/issues/3750): Please use this form and describe your issue, concisely but precisely, with as much detail as possible **Please fill out the below information:** Version 1809 (OS Build 17763.195) * Summary I updated to win10 ver 1809 today (**previously** ran 1803 without issue), and one of the first things i noticed is that when within using GNU screen the redraw is noticeably _slower_, when using _caption_ value in .screenrc. * Environment Here's the contents of an example $HOME/.screenrc: ``` caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]' ``` This is a pretty basic setting for screen to draw a floating "status bar" on the bottom showing what screen is selected, and is discussed on https://lizdenys.com/journal/articles/understanding-gnu-screens-captions.html Only **after i updated to 1809**, i noticed that when launching GNU screen from within WSL (triggered via bash.exe), and doing something that requires the screen to re-draw scrolling text, the refresh rate is pretty slow (e.g. doing something like ```ls -l /usr/bin``` takes several seconds instead of being near instance when not using that setting in screen. I've also tried resetting my environment entirely (wiping out all bash shell settings files e.g. $HOME/.bashrc and $HOME/.bash_profile). I narrowed it down to that captions always line being the culprit. I was first noticed how painful running ps auxwww was on a remote linux system :-( * What you're doing and what's happening: generating output that exceeds the size of the window, resulting in scrolling behaviour. the redraw of the text from scrolling, results in a rate that makes me think i'm back on my first 486 computer ``` $ echo "caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'" > .screenrc $ screen [... inside new screen ...] $ ls -l /usr/bin ``` * What's wrong / what should be happening instead: time to perform a simple "dir" (via ```ls -l /usr/bin```) takes ~20 seconds inside GNU screen this same listing takes only a second and a half when not using GNU screen at all (or not using that captions always line in $HOME/.screenrc) . whether or not using a screen multiplexer like GNU screen should not affect the refresh time, at least it didn't before i upgraded to win10 ver 1809 today. * Strace of the failing command, if applicable: not applicable, running the ls comand using time reports nearly identical values: outside of screen: ``` real 0m1.240s user 0m0.016s sys 0m0.063s ``` inside screen: ``` real 0m0.069s user 0m0.000s sys 0m0.063s ``` Which makes it seem that the comand isn't what's running any slower (in fact it reports it ran faster?) but the drawing the scrolling text is what's in-fact impacted.
claunia commented 2026-01-30 21:53:54 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 4, 2019):

OK, I traced out the difference here using WPR.

A regular ls -l /usr/bin without screen looks just fine.

A screened ls -l /usr/bin is causing us to think that we need to scroll a big region of the screen in a way that requires us to backup an entire region by making a copy, moving some data, and then restoring that whole region back onto a different part of the screen.

That's a very expensive operation and should be done sparingly and only when absolutely necessary.
I've recently been working on identifying optimizations in the "scrolling" algorithm to find when we really don't need to be making copies and avoiding them. However, it looks like the optimizations I've already made didn't catch this.

So I'll have to dig deeper to see if there's an optimization I can identify here to avoid the copy steps or if screen is asking for something very expensive that we can't super control. (I bet it's the former.)

I've filed MSFT: 20087862 to myself internally to continue the investigation.

@miniksa commented on GitHub (Jan 4, 2019): OK, I traced out the difference here using WPR. A regular `ls -l /usr/bin` without screen looks just fine. A `screen`ed `ls -l /usr/bin` is causing us to think that we need to scroll a big region of the screen in a way that requires us to backup an entire region by making a copy, moving some data, and then restoring that whole region back onto a different part of the screen. That's a very expensive operation and should be done sparingly and only when absolutely necessary. I've recently been working on identifying optimizations in the "scrolling" algorithm to find when we really don't need to be making copies and avoiding them. However, it looks like the optimizations I've already made didn't catch this. So I'll have to dig deeper to see if there's an optimization I can identify here to avoid the copy steps or if screen is asking for something very expensive that we can't super control. (I bet it's the former.) I've filed MSFT: 20087862 to myself internally to continue the investigation.
claunia commented 2026-01-30 21:53:54 +00:00
Author
Owner
Copy Link

@aleks-mariusz commented on GitHub (Jan 5, 2019):

thrilled you were able to replicate this, and really appreciate you investigating it so quickly, and look forward to a solution, question though, is this going to be something that can be implemented without a new insider build perhaps (a registry setting or something), or am i going to have to wait for a new win10 ver? the latter is worse for me because my org does not allow running insider builds (though i suppose if i beg i could)

as a work-around i found that if you set caption to "splitonly" instead of "always", the status bar doesn't appear until you use the split feature (ctrl+A, then S).. what i usually do is set the top split portion to minimal (ctrl+A, then :, to get the prompt, and type "resize 0").. i am using screen this way for now, but this is merely a work-around and not a real solution.

@aleks-mariusz commented on GitHub (Jan 5, 2019): thrilled you were able to replicate this, and really appreciate you investigating it so quickly, and look forward to a solution, question though, is this going to be something that can be implemented without a new insider build perhaps (a registry setting or something), or am i going to have to wait for a new win10 ver? the latter is worse for me because my org does not allow running insider builds (though i suppose if i beg i could) as a work-around i found that if you set caption to "splitonly" instead of "always", the status bar doesn't appear until you use the split feature (ctrl+A, then S).. what i usually do is set the top split portion to minimal (ctrl+A, then :, to get the prompt, and type "resize 0").. i am using screen this way for now, but this is merely a work-around and not a real solution.
claunia commented 2026-01-30 21:53:54 +00:00
Author
Owner
Copy Link

@bpkroth commented on GitHub (Jan 9, 2019):

FWIW, I'm also experiencing this issue (slow screen redraw under GNU screen session with caption always option enabled). At first disabling the new "Enable Ctrl+Shift+C/V as Copy/Paste" option for the default terminal emulator [1] seemed to restore the original redraw rate, but now it seems to always be slow so maybe that was just a red herring.

What I'd really like to see is an option similar to urxvt's skipScroll:
https://www.askapache.com/linux/rxvt-xresources/#skipScroll

[1] https://blogs.msdn.microsoft.com/commandline/2018/04/13/copy-and-paste-arrives-for-linuxwsl-consoles/

(PS: I'm willing to internally dogfood fixes for this)

@bpkroth commented on GitHub (Jan 9, 2019): FWIW, I'm also experiencing this issue (slow screen redraw under GNU ``screen`` session with ``caption always`` option enabled). At first disabling the new "_Enable Ctrl+Shift+C/V as Copy/Paste_" option for the default terminal emulator [1] seemed to restore the original redraw rate, but now it seems to always be slow so maybe that was just a red herring. What I'd really like to see is an option similar to urxvt's skipScroll: https://www.askapache.com/linux/rxvt-xresources/#skipScroll [1] https://blogs.msdn.microsoft.com/commandline/2018/04/13/copy-and-paste-arrives-for-linuxwsl-consoles/ (PS: I'm willing to internally dogfood fixes for this)
claunia commented 2026-01-30 21:53:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 9, 2019):

Alright, the underlying issue here was that we were not detecting this particular scrolling scenario as one that could be optimized. So I did a deep dive on scrolling in general. Note for our purposes here, "scrolling" is defined as effectively moving one rectangle of text in the console buffer to a new place (and backfilling the revealed area with a fill pattern).

First, I dove into the copying method itself that we were hitting at the bottom that I had identified above as very expensive. It turned out that some recent changes we made actually introduced a massive memory leak in this area. Oops. The copy method worked by allocating a rectangular area to temporarily hold some of the cells while the rest of the operations completed. But I had realized that it was a waste of time to zero construct the rectangle if it was going to be immediately filled and played some trickery. Some trickery that resulted in not destructing everything properly and leaking memory.

While working on that, I realized that we were also allocating too much heap memory for the entire rectangle. The rectangle was a heap call and then every individual cell was making another heap allocate to set up a variable length buffer to help support our UTF-8 ambitions. However, it was making the heap allocation even when it only needed to store a single character (which is the common case). We had already made provisions to use either local object storage or heap storage depending on how much data was required to draw each cell.... but we always heap allocated anyway. Oops 2.

Then while bubbling around in this area, I realized that the helper methods were causing a copy when returning their structures instead of following move semantics. That wasn't helping performance either.

Next I popped up into the scrolling algorithm itself. I knew it had fast-path detection for some forms of complete-row scrolling. And this looks like complete-row scrolling, even if it's reserving the bottom line for the status bar. The call for this scrolling was actually performed slightly weird, which was @zadjii-msft's fault :P, and the scroll region was specified with a negative position (e.g. scroll starting at line -1) and destination at the origin 0,0. Internally, the scroll algorithm sorts this out to say "well you can't scroll anything from line -1 so I'm going to just transform things downward to where that makes sense", but that transformation also caused the fast-path to get lost. I fixed the fast-path detection here and most of the performance issue went away!

But I wasn't really satisfied as I fixed one specific issue, but not the general problem.

The thing that's happening with screen is that it is using DECSTBM to create scrolling margins to represent which area of the screen moves and what doesn't. @zadjii-msft's implementation of dealing with "do a scroll while margins are intact" did something strange by moving a block of text down and then moving a block of text back up again. Supposedly to preserve the history if it floats off the top of the screen and there's a backing buffer (so stuff like dir or ls can be seeked upward in the history as long as the DECSTBM buffer includes the top row.) I asked him to look further into moving down and then back up to see if he could make this more efficient by just moving once to the final position instead of jogging text around.

Also I looked further into the Scroll method too and decided it was high time for it to be rewritten. The realization that I made was the former Scroll method looked for scenarios where either entire rows were being moved (so it could spin buffer pointers around), where the source and destination didn't overlap (so it didn't need intermediate memory at all), or where the source and destination were partially overlapping such that reading/writing from top-left to bottom-right one-row-at-a-time wouldn't require an intermediate (i.e. only when the target was above the source). In all other circumstances, it would backup the source region into a heap allocated space, fill the former source region with the fill character, and then plop the heap allocated backup down into the destination area.

But there's a trick to that. If you don't fill the whole source area with the backfill value between read and write, we can just shuffle the characters from the old to new positions by carefully choosing which direction we walk through the cells in the source and target rectangles so in the overlapping source/target case, we never accidentally write something to a source cell that hasn't been read yet for its appropriate target destination.

And of course, there's a trick to this that explains why the backup and fill method was used in the first place by whomever wrote this scroll method ages ago: there's not a really good "subtraction" mechanism for two overlapping rectangles built-in anywhere. The Win32 method SubtractRect will refuse to give you a result unless the two given parameter rectangles share 3 sides such that the result will return only one rectangle. If there's some sort of staggered offset that would make the result have 2 rectangles like an L shape, if the result would have 3 rectangles like a C shape, or if the result would have 4 rectangles like an O shape, you just get an error.

So I expanded our internal "Smart Rectangle" structure (internally called Viewport for assorted reasons, just deal with it for now) that we've been using to modernize the console and help with these sorts of problems to have a "Subtract" method that can return between 1 and 4 rectangles describing the area remaining (to be filled) after an overlapping target eats up some of the source area during a scroll operation. And then I realized that I needed to not heap allocate to return exactly [1,4] rectangles and fixed up a stack based structure for it.

I also made the Viewport understand how to walk any direction through it. Left To Right and Top to Bottom.... Bottom to Top and Left to Right.... Right to Left and Top to Bottom.... etc.

Then equipped with the Viewport updates, I rewrote the scroll method to no longer need an intermediate space. It really has 3 options now:

  1. The source and destination are the same so we can do nothing.
  2. The source and destination are moving straight up vertically and moving entire rows of text at a time so we can call our pointer rotate mechanism to just reshuffle the rows quickly
  3. We figure out where the destination origin is relative to the source origin, decide which direction we need to walk through to copy things from source to destination without a heap allocated temporary, and then do the work.

Then finally after the copy, we use the new subtraction to figure out what areas left haven't been touched, fill them, and we're good to go. Now I believe I've solved the scrolling performance issue for all cases related to scrolling a portion of text to another bit of the buffer. And there's no longer any circumstance where we need to allocate heap memory for a scroll!

Combined with @zadjii-msft's fixes that he did in the meantime to be less silly about DECSTBM calling multiple scroll commands for one operation.... I believe you'll be very satisfied with the result.

It will be coming to Insiders builds within a few weeks. Unfortunately there is no workaround for this down-level and it is unlikely to be backported as it relies on our new performance-sensitive and UTF-8 ready output buffer manipulations from this fall/winter and Viewport math abstractions that aren't in 1809 RTM.

@miniksa commented on GitHub (Jan 9, 2019): Alright, the underlying issue here was that we were not detecting this particular scrolling scenario as one that could be optimized. So I did a deep dive on scrolling in general. Note for our purposes here, "scrolling" is defined as effectively moving one rectangle of text in the console buffer to a new place (and backfilling the revealed area with a fill pattern). First, I dove into the copying method itself that we were hitting at the bottom that I had identified above as very expensive. It turned out that some recent changes we made actually introduced a massive memory leak in this area. Oops. The copy method worked by allocating a rectangular area to temporarily hold some of the cells while the rest of the operations completed. But I had realized that it was a waste of time to zero construct the rectangle if it was going to be immediately filled and played some trickery. Some trickery that resulted in not destructing everything properly and leaking memory. While working on that, I realized that we were also allocating too much heap memory for the entire rectangle. The rectangle was a heap call and then every individual cell was making another heap allocate to set up a variable length buffer to help support our UTF-8 ambitions. However, it was making the heap allocation even when it only needed to store a single character (which is the common case). We had already made provisions to use either local object storage or heap storage depending on how much data was required to draw each cell.... but we always heap allocated anyway. Oops 2. Then while bubbling around in this area, I realized that the helper methods were causing a copy when returning their structures instead of following move semantics. That wasn't helping performance either. Next I popped up into the scrolling algorithm itself. I knew it had fast-path detection for some forms of complete-row scrolling. And this looks like complete-row scrolling, even if it's reserving the bottom line for the status bar. The call for this scrolling was actually performed slightly weird, which was @zadjii-msft's fault :P, and the scroll region was specified with a negative position (e.g. scroll starting at line -1) and destination at the origin 0,0. Internally, the scroll algorithm sorts this out to say "well you can't scroll anything from line -1 so I'm going to just transform things downward to where that makes sense", but that transformation also caused the fast-path to get lost. I fixed the fast-path detection here and most of the performance issue went away! But I wasn't really satisfied as I fixed one specific issue, but not the general problem. The thing that's happening with `screen` is that it is using DECSTBM to create scrolling margins to represent which area of the screen moves and what doesn't. @zadjii-msft's implementation of dealing with "do a scroll while margins are intact" did something strange by moving a block of text down and then moving a block of text back up again. Supposedly to preserve the history if it floats off the top of the screen and there's a backing buffer (so stuff like `dir` or `ls` can be seeked upward in the history as long as the DECSTBM buffer includes the top row.) I asked him to look further into moving down and then back up to see if he could make this more efficient by just moving once to the final position instead of jogging text around. Also I looked further into the Scroll method too and decided it was high time for it to be rewritten. The realization that I made was the former Scroll method looked for scenarios where either entire rows were being moved (so it could spin buffer pointers around), where the source and destination didn't overlap (so it didn't need intermediate memory at all), or where the source and destination were partially overlapping such that reading/writing from top-left to bottom-right one-row-at-a-time wouldn't require an intermediate (i.e. only when the target was above the source). In all other circumstances, it would backup the source region into a heap allocated space, fill the former source region with the fill character, and then plop the heap allocated backup down into the destination area. But there's a trick to that. If you don't fill the whole source area with the backfill value between read and write, we can just shuffle the characters from the old to new positions by carefully choosing which direction we walk through the cells in the source and target rectangles so in the overlapping source/target case, we never accidentally write something to a source cell that hasn't been read yet for its appropriate target destination. And of course, there's a trick to this that explains why the backup and fill method was used in the first place by whomever wrote this scroll method ages ago: there's not a really good "subtraction" mechanism for two overlapping rectangles built-in anywhere. The Win32 method `SubtractRect` will refuse to give you a result unless the two given parameter rectangles share 3 sides such that the result will return only one rectangle. If there's some sort of staggered offset that would make the result have 2 rectangles like an L shape, if the result would have 3 rectangles like a C shape, or if the result would have 4 rectangles like an O shape, you just get an error. So I expanded our internal "Smart Rectangle" structure (internally called `Viewport` for assorted reasons, just deal with it for now) that we've been using to modernize the console and help with these sorts of problems to have a "Subtract" method that can return between 1 and 4 rectangles describing the area remaining (to be filled) after an overlapping target eats up some of the source area during a scroll operation. And then I realized that I needed to not heap allocate to return exactly [1,4] rectangles and fixed up a stack based structure for it. I also made the `Viewport` understand how to walk any direction through it. Left To Right and Top to Bottom.... Bottom to Top and Left to Right.... Right to Left and Top to Bottom.... etc. Then equipped with the `Viewport` updates, I rewrote the scroll method to no longer need an intermediate space. It really has 3 options now: 1. The source and destination are the same so we can do nothing. 1. The source and destination are moving straight up vertically and moving entire rows of text at a time so we can call our pointer rotate mechanism to just reshuffle the rows quickly 1. We figure out where the destination origin is relative to the source origin, decide which direction we need to walk through to copy things from source to destination without a heap allocated temporary, and then do the work. Then finally after the copy, we use the new subtraction to figure out what areas left haven't been touched, fill them, and we're good to go. Now I believe I've solved the scrolling performance issue for all cases related to scrolling a portion of text to another bit of the buffer. And there's no longer any circumstance where we need to allocate heap memory for a scroll! Combined with @zadjii-msft's fixes that he did in the meantime to be less silly about DECSTBM calling multiple scroll commands for one operation.... I believe you'll be very satisfied with the result. It will be coming to Insiders builds within a few weeks. Unfortunately there is no workaround for this down-level and it is unlikely to be backported as it relies on our new performance-sensitive and UTF-8 ready output buffer manipulations from this fall/winter and `Viewport` math abstractions that aren't in 1809 RTM.
claunia commented 2026-01-30 21:53:55 +00:00
Author
Owner
Copy Link

@aleks-mariusz commented on GitHub (Jan 10, 2019):

wow, that has to be the most in-depth concise explanation of an issue investigation and resolution proposal i've ever come across on github! kudos!

my next question would be, if i wanted to extract the fix from an insider build and slap them onto my 1809 what files would i need to copy over? once you tell me which insider build # actually has the fix of course :-)

@aleks-mariusz commented on GitHub (Jan 10, 2019): wow, that has to be the most in-depth concise explanation of an issue investigation and resolution proposal i've ever come across on github! kudos! my next question would be, if i wanted to extract the fix from an insider build and slap them onto my 1809 what files would i need to copy over? once you tell me which insider build # actually has the fix of course :-)
claunia commented 2026-01-30 21:53:55 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Jan 15, 2019):

It would be great @miniksa if you could remember to post back here when you figure out what insiders build has this immensely welcomed fix. Great work to you and @zadjii-msft -- appreciated by all users of DECSTBM.

@oising commented on GitHub (Jan 15, 2019): It would be great @miniksa if you could remember to post back here when you figure out what insiders build has this immensely welcomed fix. Great work to you and @zadjii-msft -- appreciated by all users of DECSTBM.
claunia commented 2026-01-30 21:53:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 15, 2019):

@aleks-mariusz, unfortunately I can't provide public details on how to make a frankenbuild and get you the bits early. We are working on mechanisms to make this less painful in terms of public release, but it's taking time.

@oising, I'll try. We've been trying to get better about changelogs now that we're on the list for the Insiders program folks to bother us when a new build is about to go out. We can go check what hit that build number and fill out their changelog and usually update GitHub at the same time (for bugs with GitHub tags in them). We're just many steps removed from writing our code and it actually going out, so sometimes we don't realize when exactly that is....

@miniksa commented on GitHub (Jan 15, 2019): @aleks-mariusz, unfortunately I can't provide public details on how to make a frankenbuild and get you the bits early. We are working on mechanisms to make this less painful in terms of public release, but it's taking time. @oising, I'll try. We've been trying to get better about changelogs now that we're on the list for the Insiders program folks to bother us when a new build is about to go out. We can go check what hit that build number and fill out their changelog and usually update GitHub at the same time (for bugs with GitHub tags in them). We're just many steps removed from writing our code and it actually going out, so sometimes we don't realize when exactly that is....
claunia commented 2026-01-30 21:53:55 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 8, 2019):

This fix came out with Windows Insider Build 18334! Thanks!

@DHowett-MSFT commented on GitHub (Feb 8, 2019): This fix came out with Windows Insider Build 18334! Thanks!
claunia commented 2026-01-30 21:53:56 +00:00
Author
Owner
Copy Link

@pcaheny commented on GitHub (Jun 8, 2023):

@DHowett-MSFT @miniksa I recently started using windows terminal for the first time (due to an upgrade of Win 11 21H1 -> 22H2) and I have exactly the specific problem reported in this issue (i.e. redraw of scrolling text under WSL, inside GNU screen w/ caption, is way slow). I have OS Build 22621.1702 and Windows Terminal Version: 1.17.11461.0

@pcaheny commented on GitHub (Jun 8, 2023): @DHowett-MSFT @miniksa I recently started using windows terminal for the first time (due to an upgrade of Win 11 21H1 -> 22H2) and I have exactly the specific problem reported in this issue (i.e. redraw of scrolling text under WSL, inside GNU screen w/ caption, is way slow). I have OS Build 22621.1702 and Windows Terminal Version: 1.17.11461.0
claunia commented 2026-01-30 21:53:56 +00:00
Author
Owner
Copy Link

@bpkroth commented on GitHub (Jun 8, 2023):

@pcaheny there's an option in the Terminal settings to switch back to the traditional console as a workaround.

@bpkroth commented on GitHub (Jun 8, 2023): @pcaheny there's an option in the Terminal settings to switch back to the traditional console as a workaround.
claunia commented 2026-01-30 21:53:56 +00:00
Author
Owner
Copy Link

@pcaheny commented on GitHub (Jun 9, 2023):

Thanks @bpkroth , I got to the workaround already but my post was more to find out (given this issue was closed in 2019) whether the problem is still expected to be present in the release versions of Windows and Windows Terminal that I have now?

@pcaheny commented on GitHub (Jun 9, 2023): Thanks @bpkroth , I got to the workaround already but my post was more to find out (given this issue was closed in 2019) whether the problem is still expected to be present in the release versions of Windows and Windows Terminal that I have now?
claunia commented 2026-01-30 21:53:56 +00:00
Author
Owner
Copy Link

@bpkroth commented on GitHub (Jun 9, 2023):

[like] Brian Kroth (GSL) reacted to your message:

@bpkroth commented on GitHub (Jun 9, 2023): [like] Brian Kroth (GSL) reacted to your message: ________________________________
claunia commented 2026-01-30 21:53:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 9, 2023):

If you're seeing anything like this, it's surely a different root cause. Mind filing a new issue? Pretty sure this issue predates the existence of the Terminal itself 😛

@zadjii-msft commented on GitHub (Jun 9, 2023): If you're seeing anything like this, it's surely a different root cause. Mind filing a new issue? Pretty sure this issue predates the existence of the Terminal itself 😛
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Performance Product-Conhost Resolution-Fix-Available Work-Item
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#503
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?