Terminal size mismatch - Githubissues

dolik-rce commented 7 months ago

Sometimes (I'm still not exactly sure in what exact circumstances), the terminal is kind of confused about it's size. It seems to fallback to 80x24, even though the screen size is different:

$ echo $COLUMNS $LINES
80 24

This leads to weird artifacts when rendering apps, e.g.: screen_1708516410

Changing the window size fixes the problem. It might be related to the fact that I use tiling window manager (sway).

Most of the time, changing the window geometry works just as expected. This weird thing happens only sometimes. I'll try to keep an eye on it, maybe I'll be able to better pinpoint what leads to this phenomenon.

ismail-yilmaz commented 7 months ago

This is interesting. A couple of questions:

Is it happening on (un)maximize window?
Is it happening when running htop the first time (I am asking this because htop on TERM=xterm-256color uses the alternate buffer and the alternate buffer's page size should then be initizalized to the actual page size.)

dolik-rce commented 7 months ago

Is it happening on (un)maximize window?

Hard to say, there is no "maximize" in a tiling manager :-) I still haven't found a sequence of actions that would reliably reproduce it...

Is it happening when running htop the first time

It happens even if I close htop and open it again. Same thing happens in other apps, I've noticed it in less, nano and even in plain bash (if I write long enough command, it wraps at column 80).

dolik-rce commented 7 months ago

It might be also related to a resize when I plug in external monitor, because the desktop where I have the open terminals gets moved to the bigger monitor. I'll try to test that on Monday, when I get to the office.

ismail-yilmaz commented 7 months ago

Is it happening on (un)maximize window?

Hard to say, there is no "maximize" in a tiling manager :-) I still haven't found a sequence of actions that would reliably reproduce it...

Is it happening when running htop the first time

It happens even if I close htop and open it again. Same thing happens in other apps, I've noticed it in less, nano and even in plain bash (if I write long enough command, it wraps at column 80).

Then we have a buffer resize, not rendering issue, at least. Is size hint enabled? What does it report? And most importantly, is this a new thing, did it also occur earlier (I suspect a regression).

dolik-rce commented 7 months ago

Is size hint enabled?

No, I have that turned of, it was kind of distracting. But I'll try to add some logging to the resizing code. This way, I'll have a trace of what happened before the problem occurs.

And most importantly, is this a new thing, did it also occur earlier (I suspect a regression).

I believe it's there since I started using Bobcat, or at least couple weeks. So probably nothing you changed lately.

dolik-rce commented 7 months ago

I have added this LOG into TerminalCtrl::SyncSize:

    RLOG(
        "["<< getpid() <<"] "
        << GetSysTime() << " SyncSize "
        << page->GetSize()
        << " -> " << newsize
        << " Ctrl: " << GetSize()
    );

It logs a lot of interesting information even when the problem doesn't manifest (I have manually added annotations of my actions):

// Bobcat started
[3353843] 02/22/2024 17:52:25 SyncSize (2, 2) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (2, 2) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (2, 2) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (2, 2) -> (213, 1) Ctrl: (1920, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (2, 2) -> (213, 60) Ctrl: (1920, 1080)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (1, 1) Ctrl: (0, 0)
[3353843] 02/22/2024 17:52:25 SyncSize (213, 60) -> (80, 24) Ctrl: (720, 432)
[3353843] 02/22/2024 17:52:25 SyncSize (80, 24) -> (106, 56) Ctrl: (958, 1009)
[3353843] 02/22/2024 17:52:25 SyncSize (106, 56) -> (106, 56) Ctrl: (958, 1009)
// resized by user
[3353843] 02/22/2024 17:52:31 SyncSize (106, 56) -> (213, 26) Ctrl: (1920, 478)
// resized by user
[3353843] 02/22/2024 17:52:36 SyncSize (213, 26) -> (106, 56) Ctrl: (958, 1009)

As you can see, at the start the application gets a ton of layout changes, with many intermediate states. They are:

1920x1080: full size of my monitor.
720x432: no idea where this came from :shrug:
958x1009: correct size, when it runs vertically splitted (so half the screen minus window decorations)
1920x478: correct size, when it runs splitted horizontally which is what I did to test the resize)

Is it possible that the app may sometimes miss some of those resize events and stay in the intermediate state? Or maybe the weird resize event just comes sometimes while the application runs, not just when it is starting...

dolik-rce commented 7 months ago

Regarding 720x432: that is probably computed from the default page_size, when Bobcat starts. I've noticed there is if(!IsMaximized()) SetPageSize(size); in Bobcat::Run. It doesn't make much sense in tiling WM, but it's correct in most circumstances and should not be a problem.

I'll just run the modified code with logging until I notice the problem again, maybe we'll get some more insight from that.

ismail-yilmaz commented 7 months ago

As you can see, at the start the application gets a ton of layout changes, with many intermediate states.

Those calls appear to be perfectly normal. Several methods that can affect the page geometry immediately call the Layout() method. E.g. Font, padding, etc. Terminal::SetProfile method in Bobcat calls them sequentially, so you'll get a lot of layout calls. However, only the ones that actually change the geometry (page size) is processed in Layout method. Even the below code calls it several times:

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

struct MyCtrl : Ctrl {
    void Layout() override
    {
        RDUMP(GetSize());
    }
};
struct TestApp : TopWindow {
    MyCtrl ctrl;
    TestApp()
    {
        Sizeable().Zoomable().CenterScreen().SetRect(0, 0, 640, 400);
        Add(ctrl.SizePos());
    }
};

GUI_APP_MAIN
{
    StdLogSetup(LOG_FILE);
    TestApp().Run();
}

Result:

GetSize() = (1920, 0)
GetSize() = (1920, 1048)
GetSize() = (640, 400)
GetSize() = (640, 400)

Tomorrow I'll have time to test Bobcat in sway too.

ismail-yilmaz commented 7 months ago

I installed sway in VM but couldn't manage to reproduce the problem. :/

dolik-rce commented 7 months ago

I installed sway in VM but couldn't manage to reproduce the problem. :/

Don't worry, I still couldn't reproduced it either. But I'm still running the modified version with logging, so I hope it will help me to narrow it down.

I'm well aware that this bug report is very imprecise and not much actionable... Please just ignore it, until I can gather some mor information on how to reproduce it.

dolik-rce commented 7 months ago

I have finally caught the problem again, so I have few more clues.

It happened after I woke the laptop from overnight sleep. I've had three open terminals, one running local profile with bash, two with ssh to a remote host. The local profile is just ok, but both with the ssh command report default size.

 $ echo $COLUMNS $LINES
80 24

The log doesn't show anything out of the ordinary:

[3631856] 02/26/2024 10:15:14 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 11:41:13 SyncSize (131, 87) -> (131, 88) Ctrl: (1186, 1414)
[3631856] 02/26/2024 11:41:14 SyncSize (131, 88) -> (98, 64) Ctrl: (889, 1035)
[3631856] 02/26/2024 11:41:45 SyncSize (98, 64) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:23:42 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:23:56 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:55:52 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:56:10 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 15:02:10 SyncSize (131, 87) -> (131, 88) Ctrl: (1186, 1414)
[3631856] 02/26/2024 15:02:11 SyncSize (131, 88) -> (98, 64) Ctrl: (889, 1035)

Last timestamp is from yesterday. This just means, that there was no resize events since I closed the lid.

So the problem happens when the ssh connection times out and the command is restarted (the profile specifies On exit: Restart command).

Now I can reproduce it even in local profile, if I set "restart command" and kill the shell. It starts a new one just right, but doesn't propagate the size info to the restarted command. I believe this should be pretty easy to fix now :-)

ismail-yilmaz commented 7 months ago

I have finally caught the problem again, so I have few more clues.

It happened after I woke the laptop from overnight sleep. I've had three open terminals, one running local profile with bash, two with ssh to a remote host. The local profile is just ok, but both with the ssh command report default size.
 $ echo $COLUMNS $LINES
80 24
The log doesn't show anything out of the ordinary:
[3631856] 02/26/2024 10:15:14 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 11:41:13 SyncSize (131, 87) -> (131, 88) Ctrl: (1186, 1414)
[3631856] 02/26/2024 11:41:14 SyncSize (131, 88) -> (98, 64) Ctrl: (889, 1035)
[3631856] 02/26/2024 11:41:45 SyncSize (98, 64) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:23:42 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:23:56 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:55:52 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 13:56:10 SyncSize (131, 87) -> (131, 87) Ctrl: (1186, 1395)
[3631856] 02/26/2024 15:02:10 SyncSize (131, 87) -> (131, 88) Ctrl: (1186, 1414)
[3631856] 02/26/2024 15:02:11 SyncSize (131, 88) -> (98, 64) Ctrl: (889, 1035)
Last timestamp is from yesterday. This just means, that there was no resize events since I closed the lid.

So the problem happens when the ssh connection times out and the command is restarted (the profile specifies On exit: Restart command).

Now I can reproduce it even in local profile, if I set "restart command" and kill the shell. It starts a new one just right, but doesn't propagate the size info to the restarted command. I believe this should be pretty easy to fix now :-)

Thank you very much!

Yes, I can now replicate and confirm that.

Tried to fixed that, (commit 0df9dbd.)

Please check.

dolik-rce commented 7 months ago

Yes, it seems to work just fine now. Thank you.

ismail-yilmaz / Bobcat

Terminal size mismatch #25