FarGroup
Increasing the Far3 window size creates panel artifacts in the console window
Far Manager version
3.0.6249.0
OS version
Windows 7, 10, 11
Other software
No response
Steps to reproduce
Increase windows size, mostly width, by dragging by the corner or border, or increase width through Windows Properties->Layout->Windows Size->Width. Switch to Console window (Ctrl+O).
It maybe related to similar issues #765 and #257
Expected behavior
Clean Console window.
When having a few monitors with different resolutions (like laptop with external monitors) it's quite frequently requited to resize windows including Far3.
Actual behavior
Multiple artifacts from Panels drawing:
When dragging for the corner:
When using Properties->Layout->Windows Size->Width:
Problem exists with Legacy console too. Loos like Far 2.0 doesn't have that problem.
Hi @Zeroes1. No, option is checked, actually I see the problem regardless of this option, checked or not. Just increase the window size (reduce it first if it's too big from the beginning).
Loos like Far 2.0 doesn't have that problem
Far 2 is a bug-free perfection. It is known.
Oh wai...
@yulian5 Zeroes's suggestion is correct. When the option is checked, the host actively tries to break things, not much we can do about it.
Hi @alabuzhev, that's interesting about Far2. I was not able reproduce that, tried just now. I mentioned about Far2 just in case that it may be new related changes in Far3 that you know. Not to prove that Far2 is better, Far2 is history now, I just have it on one of my computers.
not much we can do about it.
Far3 is drawing on the console canvas. It should be a way to fix that problem.
When the option is checked
When option is not checked there are also artifacts, just in less degree:
Original post about resizing was correct. It happens not only while increasing the windows size but when decreasing as well:
When option is not checked there are also artifacts, just in less degree
Conhost being conhost. When it enlarges the window, it uses the colors of the rightmost column for the new cells. Why? No idea. I implemented a workaround for this years ago (by re-filling those areas with the default color manually), and it even worked back in Windows 7 or so. In 10 MS reworked the host a lot and broke a lot as well, so I'm not surprised that it happens again. However, this particular issue is potentially fixable.
not only while increasing the windows size but when decreasing as well
Your screenshot shows a graphical artefact outside of the screen buffer. I'd be happy to fill that one too, but see above: it's outside of the screen buffer.
Far3 5555 is history too.
@w17 Good joke. Why do you think so? Regarding this problem they're the same.
You try use Windows Terminal?
@Zeroes1 What do you mean? I think the problem is integration Far3 with Conhost.
Originally I thought it's just a redrawing problem for empty space. But it looks more serious now. Let me add some screenshots.
@alabuzhev mentioned:
I implemented a workaround for this years ago (by re-filling those areas with the default color manually), and it even worked back in Windows 7 or so.
Actually for Windows 7 it's the same problem (sorry for historic Far3 6116):
Far can work with Windows Terminal without conhost under Win10/11/srv2022 try for example https://aka.ms/terminal-canary-zip-x64 it's portable build
@alabuzhev said:
Conhost being conhost. When it enlarges the window, it uses the colors of the rightmost column for the new cells. Why? No idea. I implemented a workaround for this years ago (by re-filling those areas with the default color manually),
It looks now that mentioned workaround erased most content of Conhost window inside Far. Please see the screnshots (latest Windows, latest Far3).
Running Conhost and Far3, the same size, print directory, reduce the width, then increase width to previous value. Conhost itself is doing fine, but Far3 console window is not.
Far can work with Windows Terminal without conhost under Win10/11/srv2022
@Zeroes1 How can I replace console in Far3?
for example try my settings? unpack for example C:\UTILITY\Terminal Microsoft.WindowsTerminalCanary_latest_x64.zip unpack my settings.7z to \terminal\settings\ change settings.json "commandline": "C:\Far4\Far.exe", to yours path make link to desktop run...
change font too
or make default profile himself :) settings.zip
It looks now that mentioned workaround erased most content of Conhost window inside Far.
It's unrelated. The erasure is by design.
Can this MS Conhost code help in that problem?
Depends. You've mentioned like 10 different issues here already. Some of them can (and should) be addressed in conhost, like reusing rightmost colors for new cells on resize and visual artefacts in the gap between the buffer and the window edges, some other are by (new) design and will likely be rejected.
@Zeroes1 Thanks! I was able to run WT based on your instructions with your settings. But I see the same problem. Do I need to adjust something else? Can you check on your system? Just make Far3 smaller and increase the width with both panels on.
@alabuzhev
It's unrelated. The erasure is by design.
Why is that? Conhost doesn't erase anything after resizing.
You've mentioned like 10 different issues here already.
Sorry. Discussion went wild. Can you just select one fixable issue for this ticket? I do not have enough Far3 knowledge to properly separate them. I didn't expect so many of them from resizing. But I'm going to create one more ticket for resizing issue which is separate for sure.
some other are by (new) design and will likely be rejected.
Why is that? Don't we all want to fix Far Manager problems?
Why is that? Conhost doesn't erase anything after resizing.
"Wrap output on resize" assumes that all the output is static and stream-like. When you resize with the option enabled, the host takes the text, reformats it to the new width and puts it back. cmd.exe doesn't have any UI, commands like dir generate static stream-like text, so everything kinda works more or less as expected: the host does its thing, cmd.exe doesn't interfere, doesn't care, doesn't even notice.
Far isn't cmd.exe. It does have dynamic UI, represented as structured, table-like blocks of text. It doesn't make any sense to reparse it on resize, so the host makes things only worse, as can be seen on your very first screenshot. The output of dir, started from Far, is not a stream of text anymore, it's a text screenshot of it and basically a part of Far UI at this point. When the buffer is resized, that screenshot is trimmed to the new size as well, so everything that doesn't fit is lost forever.
Having said that, in theory we can skip that trimming and keep the captured output as is, hoping that it will be useful if the user enlarges the buffer again later. A rare scenario, but I won't mind if you create a new issue with a reference to this comment just in case.
Can you just select one fixable issue for this ticket?
https://github.com/FarGroup/FarManager/issues/772#issuecomment-1883612251 and https://github.com/FarGroup/FarManager/issues/772#issuecomment-1883617802 are actual (and likely entirely unrelated) conhost issues that should be relatively easy to fix.
Why is that?
Let's say these days MS is more interested in aligning with "other operating systems" in the command-line application space than in maintaining 100% backwards compatibility.
@yulian5 ON this
problem still exist? I no have trouble, i change size by mouse.
@alabuzhev, thanks for detailed info!
https://github.com/FarGroup/FarManager/issues/772#issuecomment-1883612251 and https://github.com/FarGroup/FarManager/issues/772#issuecomment-1883617802 are actual (and likely entirely unrelated) conhost issues that should be relatively easy to fix.
Sounds good to me! Anyway too many problems at once.
@Zeroes1 I tried that. The same rendering problem. Strange that you cannot see it: Make Far window small with mouse, then make it big with both blue panels ON. Then turn OFF the panels (Ctrl+O) and check the console screen.
I'm not sure exactly what "Use Virtual Terminal for rendering" means. Just found one more small problem, F1 help for this screen doesn't describe it.
@Zeroes1 It looks like we have some misunderstanding about WT you mentioned before. I thought we're talking about replacing console inside Far instead of Conhost with something else not running Far from another console.
@yulian5
ran: far:config search: System.WindowMode set to FALSE
re run FAR
better?
@alabuzhev
Having said that, in theory we can skip that trimming and keep the captured output as is, hoping that it will be useful if the user enlarges the buffer again later. A rare scenario
At least that part is quite clear for me. But by default the text buffer is quite big like 3000 or 9000 lines. Changing width even to extreme small size still preserves quite a big buffer. Trimming lines doesn't feel right, especially when after enlarging they are filled with garbage. And user can copy that garbage as a text.
BTW Far2 has exactly the same trimming problem. But I still cannot reproduce other garbage in Far2, it always black console screen for me with trimmed text after resizing. Far2 doesn't honor height changes well.
@alabuzhev Far3 5555 has serious panels rendering problems after changing size with keyboard through Windows Alt menu. But I do not see that with the latest 6249. Are there some related rendering changes between those two versions?
@Zeroes1
System.WindowMode set to FALSE
Thanks! That much better in this regard. Always black console window without extra rendering garbage. Still trimmed text but that is already expected. But one additional problem now: Far3 doesn't honor reducing the height. When I shrink the height I have to scroll to see the bottom or the top.
I don't know if there is a connection with the discussion above, but I also want to add about resizing the FAR window. Original FAR window:
After starting fullscreen game with lower screen resolution:
After exiting game Windows restores desktop resolution, but FAR windows doesn't (see previous screenshot). I am trying to restore the contents of the window via double Alt-F9, without restarting the program, but...
