Add recommendation for Windows Terminal to readme?
electroly opened this issue · 11 comments
I'm sure you saw this as I see you commented on the issue, but microsoft/terminal#376 was finally fixed. It's shipping right now in "Windows Terminal Preview". I tested it and the mouse now works with TMBASIC. At long last, we have 256 color support, full Unicode with fallback, and mouse support on Windows. I'm going to make the explicit recommendation for TMBASIC that people use Windows Terminal.
Hi, Brian! Thanks for the comment. Well, I for one don't like Windows Terminal that much. I think the classic console still has two important advantages when using Turbo Vision applications:
- Box-drawing characters are prettier (especially the
TDesktopdot grid). - It does not slow down when moving
TWindows around.
I just checked again just to make sure these issues hadn't been fixed recently, and indeed they haven't:
2021-05-28.00-07-50.mp4
So I don't really feel like advicing anyone to use Windows Terminal...
Cheers.
Yeah, I noticed the performance problem after opening this issue. It really is quite sluggish. The performance scales inversely with the size of the console window and also the size of the content you are moving around. At 80x25 it's not terrible, but at bigger sizes it gets increasingly painful. If I maximize the window, I get less than one frame per second when dragging a window around. That's a serious bummer. I fully expect people to resize their console windows to get more work space.
I also found some kind of bug with the mouse wheel. If you spin the wheel up and down a bit in a scrollable listbox, editor, or help window, eventually one of the wheel events will bypass tvision and hit the terminal itself, which scrolls up and displays corrupted scrollback lines. In conhost it knows to disable the scrollbar entirely.
That said, it looks good on a hi-DPI display. No issues for me there. I'm left with a bit of a quandary -- if I can't recommend Windows Terminal, then I have to instead recommend that people limit themselves to the Unicode characters that Consolas contains (no emojis) and they can't rely on 256 colors being available.
With some more testing, I have a hunch that the mouse wheel problem is related to the performance problem. I can't tell for sure, but it seems like the wheel event might bypass tvision if it's in the middle of updating the screen from a previous scroll event. If I make the help window very small, it's difficult to reproduce. If I make it very large to exaggerate the slowness, then the scroll wheel becomes nearly unusable as it scrolls the terminal right away.
In any event I agree with your conclusion -- Windows Terminal isn't ready to recommend yet for tvision-based programs. Should we close the issue and take another look after WT has had some more development time?
and they can't rely on 256 colors being available.
Well, Conhost does support true color, but Turbo Vision does not take advantage of it because I haven't investigated yet in what circumstances it is safe to assume more that 16 colors are available, given that Conhost and Windows Terminal are not the two only terminal emulators available on Windows.
tvision/source/platform/win32con.cpp
Lines 362 to 365 in a1b4887
If it works under Windows Terminal, it's probably because it defines the TERMCOLOR environment variable and Conhost doesn't.
tvision/source/platform/termdisp.cpp
Lines 22 to 24 in 287fc13
If I make the help window very small, it's difficult to reproduce. If I make it very large to exaggerate the slowness, then the scroll wheel becomes nearly unusable as it scrolls the terminal right away.
When I faced this issue time ago I got the impression that the performance issue is related to the box-drawing characters, and maybe to non-ASCII characters in general. Even text selection with Shift+click is sluggish.
Should we close the issue and take another look after WT has had some more development time?
We can leave this open as a follow-up issue of Terminal problems that make Turbo Vision applications unusable, since other people may also run into them.
Cheers.
Interesting, I didn't know about the true color support in conhost. That would be lovely to support if possible. I have a hacky suggestion that might not meet your quality bar, but it's the first thing that came to mind:
My gut tells me it's probably possible with some Win32 calls to find the tree of process IDs starting with the terminal emulator at the root and ending with our tvision app at the leaf. I bet they're all part of the same Win32 job. Once we have the root process ID, we can find out what executable it is -- if it's conhost.exe, then we're in the Windows console and not some other terminal emulator.
Once we know that, I think it's a matter of determining whether the version is new enough to include the true color support. We can read the file version from the conhost.exe path that we got from the root process ID.
This all sounds pretty rough and tumble to me, but I think I could do it.
A much dumber but simpler idea: could you give me a function to call that just forces true color mode on, letting the client program take the responsibility of making the decision in cases where it's difficult, messy, or impossible for tvision to know for sure? I think individual client programs can choose to be more liberal about compatibility whereas the base tvision library necessarily must be conservative.
The issue tracking this problem is microsoft/terminal#1040. But now I remembered that I can just check whether ENABLE_VIRTUAL_TERMINAL_PROCESSING has been set successfully; this makes it possible to distinguish between Windows 10 and older versions. On Windows 10, relevant terminal emulators using the ConPTY API (Git Bash, Alacritty, VS Code) also support 24-bit color. Older terms not using the ConPTY API but ReadConsoleOutput will just see the output truncated to 16 colors, although Turbo Vision won't be aware of this. This is in contrast to Unix, where all terminals always parse terminal sequences directly and we run the risk of garbling the display if we print escape sequences which the terminal won't understand.
My gut tells me it's probably possible with some Win32 calls to find the tree of process IDs starting with the terminal emulator at the root and ending with our tvision app at the leaf. I bet they're all part of the same Win32 job. Once we have the root process ID, we can find out what executable it is -- if it's conhost.exe, then we're in the Windows console and not some other terminal emulator.
Consoles in Windows are not always created via forking as on Unix. Instead, they can be attached and detached from a process using functions like AllocConsole and FreeConsole, so the process tree is probably not a very reliable source of information.
Nice, thank you! I will subscribe to that tracking issue, but your commit e5c1ac7 should do the trick, right? I'm happy as long as the major terminals are supported. That means that Unicode fallback is the only thing missing on conhost, and I already made my peace with that. The colors are more important than the full gamut of Unicode characters, for me.
Yes, that commit should do the trick.
I also found microsoft/terminal#6974 is the issue tracking the bad performance problem.
I gave it a test and it works great! Thanks again. I have now implemented a true-color version of my color picker which looks great in conhost. I worked around microsoft/terminal#6974 by simply changing the background pattern to a space and choosing a nice color from the 256 color palette instead. Performance is still comparatively poor, but it's much better without those characters in the background.
That looks great! Congratulations.
Yes, you'll see that replacing the background pattern with spaces improves performance on many terminals, including Konsole.