Please support the latest (new) Windows Terminal

[fiso64]

When continuously adding new progress bars and it is run in the new windows terminal and it starts scrolling, the progress bars do not behave properly. I'm not sure how to describe what happens, but here's a minimal example:

        static SemaphoreSlim semaphore = new SemaphoreSlim(2);

        static void Main(string[] args)
        {
            var random = new Random();
            var tasks = new List<Task>();
            var bars = new List<ProgressBar>();

            Console.WriteLine(".\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n.\n");

            for (int i = 0; i < 10; i++)
            {
                tasks.Add(Task.Run(() => ManageTasks(random, bars)));
            }

            Task.WaitAll(tasks.ToArray());
        }

        static async Task ManageTasks(Random random, List<ProgressBar> bars)
        {
            while (true)
            {
                await semaphore.WaitAsync();

                Task.Run(async () =>
                {
                    var fileCount = random.Next(1, 50);
                    var bar = new ProgressBar(fileCount);
                    lock (bars) bars.Add(bar);
                    bar.Refresh(0, $"New Task {bars.Count}");

                    for (int j = 0; j < fileCount; j++)
                    {
                        bar.Next($"File {j + 1}");
                        await Task.Delay(random.Next(10, 100));
                    }

                    semaphore.Release();
                });
            }
        }

It works fine in the default cmd on windows.

[fiso64]

Also, when I run this in git bash, no progress bars are displayed at all.

[goblinfactory]

Txs @fiso64 fiso64 for reporting this; I'll take a look at this tomorrow.
the detailed code sample is super helpful, thank you.
cheers, Alan

[goblinfactory]

@fiso64 deleted an earlier comment; I'll take a look at this later today.

note to self;
test to see if ProgressBar from https://github.com/goblinfactory/konsole works with this code.

(It's mostly the same code; that's also my project; I just carved out the ProgressBar to be standalone, and Konsole package receives many more updates due to it having many more users. Need to check if this problem is already fixed in Konsole.)

[goblinfactory]

Your sample code has errors in it. I've just tested 'ProgressBar' on Windows using the following much simpler code and it appears to be working correctly. I'm closing this issue as not a bug. If you still find you have issues, please use the code below as a guide of how to use ProgressBar in a concurrent situation.

using Konsole;

class Program
{
    static async Task Main(string[] args)
    {
        var rnd = new Random();

        for (int i = 1; i <=     100; i+=2)
        {
            // run two progressbars at a time in parallel
            await Task.WhenAll(
                Task.Run(()=> DownloadFiles(rnd, i, $"FILE {i}")),
                Task.Run(()=> DownloadFiles(rnd, i+1, $"FILE {i+1}"))
                );
        }
    }

    static void DownloadFiles(Random rnd, int cnt, string title)
    {
        var fileCount = rnd.Next(1, 50);
        var bar = new ProgressBar(fileCount);
        bar.Refresh(0, $"New Task {cnt}");

        for (int j = 1; j <= fileCount; j++)
        {
            bar.Next($"Progressbar {cnt}, {j + 1} files.");
            Task.Delay(rnd.Next(10, 100));
        }
    }
}

this gives me the following output

[fiso64]

1. I don't think my code has any errors.
2. Regardless of that, this is an issue about windows terminal. Try your code in windows terminal (NOT cmd.exe), you'll see that progress bars are not displayed properly. I just tried it.

As you can see, many of them aren't at 100%. Also, note that some are duplicated (e.g progress bar 98 and 100 appear on two different lines).

[goblinfactory]

Ah, that's helpful to know, thank you. I've re-opened the issue and renamed it to be more specific.
I've not used windows for a few years. I had to fire up my backup windows machine in order to do the test above.
I'll test it with the new "Terminal"; I didnt even know they made changes to windows terminal's compatibility so will have to start with understanding what they broke in terms of compatibility.

[goblinfactory]

@fiso64
At a guess, It looks like some kind of problem with the console's "eventual consistency" on reporting on current Y position of the console. As you pointed out there's two progress bar 98's; which suggest the console reports the current line for a ProgressBar is x, then it scrolls, and you write to x, and it's already shifted, however, given that it completes the rest of the rendering correctly on the new line suggests that the correct (new line Y position) eventually catches up some milliseconds later?? so maybe there's a kind of message pump for the new console write updates that's not compatible with the old console API. It's possible it's something else, but unfortunately this may take a few days before I can get a patch out in between critical work I'm doing on my new startup ; BigNameHunter.com. Taking another crazy random guess without having read anything at all about what the new console actually does, I'd guess there's some new API methods to do something like "suspend-paint" and "resume-paint" ... to allow for very high speed writing. Dunno, all total speculation / guessing. Will be interesting to find out what they did.

Given that the update will need to work with a totally new platform rendering engine is why I'm saying it will be at the very least a few days. (managing expectations)

[goblinfactory]

Updates; some reading and possibly ?? related issues in the new terminal

Random list of some light reading. Items may have nothing to do with the issue;

• Setting cursor position has too many routes microsoft/terminal#2739 ( Setting cursor position has too many routes )
• Vanishing cursor and prints to wrong lines microsoft/terminal#7479 ( Vanishing cursor and prints to wrong lines )
• We don't update LPWINDOWPOS flags during WM_WINDOWPOSCHANGED, maybe we should? microsoft/terminal#12924 ( We don't update LPWINDOWPOS flags during WM_WINDOWPOSCHANGED, maybe we should? #12924 )
• Automatic scrolling of window when setting cursor position microsoft/terminal#14774 ( Automatic scrolling of window when setting cursor position #14774 )
• ResizeWithReflow doesn't clamp _virtualBottom if the cursor is above the viewport microsoft/terminal#17023 ( ResizeWithReflow doesn't clamp _virtualBottom if the cursor is above the viewport #17023)
• [megathread] ConPTY buffer gets out-of-sync  microsoft/terminal#15976 ( [megathread] ConPTY buffer gets out-of-sync #15976 )

note;
I dont see any obvious smoking gun in this list, which may be good news; I'm hoping a simple logical change in ProgressBar code can work around any differing behaviours.

[goblinfactory]

Update: hi @fiso64 : I thought it only appropriate to let you know that I'm not going to be able to work on this any time soon. There's not enough users of ProgressBar that have engaged with me (the developer), other than yourself, and unfortunately your immediate need is to support a new platform it wasn't designed to support, since clearly the new console in some small but critical way is not 100% backward compatible with the old windows console behavior.

I'm leaving this open, so that others can see the discussion, but labelling this as "not a bug"; it's a feature request to support a new platform.

As I said in my comments above, there might be a simple fix. Feel free to fork the project, and I'll happily accept a Pull Request to patch it. Best of luck, A
(

[fiso64]

Completely understand. Thanks for looking into this.