<blockquote>
<p dir="auto">Please use this form and describe your issue, concisely but precisely, with as much detail as possible</p>
</blockquote>
<blockquote>
<ul dir="auto">
<li>Your Windows build number:  (Type <code class="notranslate">ver</code> at a Windows Command Prompt)</li>
</ul>
</blockquote>
<p dir="auto">Microsoft Windows [Version 10.0.17763.379]</p>
<blockquote>
<ul dir="auto">
<li>What you're doing and what's happening: (Copy &amp; paste specific commands and their output, or include screen shots)</li>
</ul>
</blockquote>
<p dir="auto">In less, scrolling down (f) is instantaneous, but scrolling up (u) is extremely slow.  For example, if I open <code class="notranslate">man man</code> and hold <code class="notranslate">f</code>, it takes about 1 second to scroll to the end, but if I hold <code class="notranslate">u</code>, it will take about 10 seconds to scroll back to the top.</p>
<p dir="auto">Behavior is similar if I run <code class="notranslate">less</code> on a remote system through SSH, although in that case scrolling up gives the appearance of being 'jerkier'.</p>
<p dir="auto">repasting details from <a href="https://github.com/Microsoft/WSL/issues/3750" data-hovercard-type="issue" data-hovercard-url="/microsoft/WSL/issues/3750/hovercard">here</a>:</p>
<p dir="auto">Please use this form and describe your issue, concisely but precisely, with as much detail as possible</p>
<p dir="auto"><strong>Please fill out the below information:</strong><br>
Version 1809 (OS Build 17763.195)</p>
<ul dir="auto">
<li>
<p dir="auto">Summary<br>
I updated to win10 ver 1809 today (<strong>previously</strong> ran 1803 without issue), and one of the first things i noticed is that when within using GNU screen the redraw is noticeably <em>slower</em>, when using <em>caption</em> value in .screenrc.</p>
</li>
<li>
<p dir="auto">Environment<br>
Here's the contents of an example $HOME/.screenrc:</p>
</li>
</ul>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'"><pre class="notranslate"><code class="notranslate">caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'
</code></pre></div>
<p dir="auto">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 <a href="https://lizdenys.com/journal/articles/understanding-gnu-screens-captions.html" rel="nofollow">https://lizdenys.com/journal/articles/understanding-gnu-screens-captions.html</a></p>
<p dir="auto">Only <strong>after i updated to 1809</strong>, 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 <code class="notranslate">ls -l /usr/bin</code> takes several seconds instead of being near instance when not using that setting in screen.</p>
<p dir="auto">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 :-(</p>
<ul dir="auto">
<li>What you're doing and what's happening:<br>
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</li>
</ul>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$ echo &quot;caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'&quot; &gt; .screenrc
$ screen
[... inside new screen ...]
$ ls -l /usr/bin"><pre class="notranslate"><code class="notranslate">$ echo "caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'" &gt; .screenrc
$ screen
[... inside new screen ...]
$ ls -l /usr/bin
</code></pre></div>
<ul dir="auto">
<li>What's wrong / what should be happening instead:<br>
time to perform a simple "dir" (via <code class="notranslate">ls -l /usr/bin</code>) takes ~20 seconds inside GNU screen</li>
</ul>
<p dir="auto">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) .</p>
<p dir="auto">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.</p>
<ul dir="auto">
<li>Strace of the failing command, if applicable:<br>
not applicable, running the ls comand using time reports nearly identical values:</li>
</ul>
<p dir="auto">outside of screen:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="real    0m1.240s
user    0m0.016s
sys     0m0.063s"><pre class="notranslate"><code class="notranslate">real    0m1.240s
user    0m0.016s
sys     0m0.063s
</code></pre></div>
<p dir="auto">inside screen:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="real    0m0.069s
user    0m0.000s
sys     0m0.063s"><pre class="notranslate"><code class="notranslate">real    0m0.069s
user    0m0.000s
sys     0m0.063s
</code></pre></div>
<p dir="auto">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.</p>