Sixel images distorted; sixel images have too much bottom padding; sixel causes buffer full error

[jessebot]

💌 Thank you note (that has nothing to do with the bug)

Thank you for working on zellij! 💙 I have been using it daily for only a week and it's already totally replacing tmux for me (and I'd been using screen/tmux since 2012!). I do a lot of screen sharing from my mac to a linux machine using a projector while I'm coding, so that my partner and I can hack on cool projects together in vim/neovim. They can then also jump into the same session when we're done rubberducking. This tool has totally changed how we work together and I promise when I have time, I will post some pictures of just how cool and hacker aesthetic this looks when we have two tiny screens and one major screen running zellij sessions to manage everything from spotify to email to small python projects to active development of larger scale kubernetes projects :) Being able to have beautiful tabbing, floating windows, and fast splits, really means a lot to our productivity, so thank you so much. I will try to sponsor when I am not also a poor dev.

I'm having some issues with sixel support, mostly happening when scrolling after displaying an image somewhere. The image prints okay, but with a lot of padding on the bottom of empty space, and then you scroll, it breaks up, sometimes over writing the rest of the screen buffer and making it unreadable. If it gets too bad, zellij will crash. This happens on iterm2 (macOS) and wezterm (Ubuntu). The problem is particularly pronounced when using w3m, but also happens just using img2sixel directly on the command line. (in the screenshots/video below, sixel is an alias to img2sixel)

In Case of Graphical or Performance Issues

1. _Delete the contents of /tmp/zellij-1000/zellij-log, ie with cd /tmp/zellij-1000/ and rm -fr zellij-log/
2. Run zellij --debug
3. Run stty size, copy the result and attach it in the bug report
4. Recreate your issue.
5. Quit Zellij immediately with ctrl-q (your bug should ideally still be visible on screen)

I tried to do the above on my mac, but no there is no directory called /tmp/zellij-* on my mac, so I just recorded a little video for you here:

https://user-images.githubusercontent.com/2389292/209536832-19ad0aa1-a677-4438-b5d0-3a1e30af6361.mp4

On Ubuntu running wezterm, the same issue with sixel seems to happen, but this time with logs (when I ran an experiment with a different picture of a dog on wezterm on Ubuntu, it crashes): zellij-9.log zellij.log

Also noteworthy is that after zellij crashes with Error occurred in server: Buffer full, it can't be launched again until you delete the hung process (this happens on both Ubuntu and macOS):

# ps aux | grep zell
friend    207864  0.1  0.2 13898484 45800 ?      Sl   10:23   0:00 /home/linuxbrew/.linuxbrew/Cellar/zellij/0.34.4/bin/zellij --server /run/user/1000/zellij/0.34.4/available-muscle --debug

Basic information

(this happens on macOS -iterm2, and Debian/Ubuntu -wezterm)

zellij --version: zellij 0.34.4 (same version on all machines)

stty size: 43 143 (this is from my 13 inch macbook that I use to access sessions locally but also sessions on Debian/Ubuntu)

uname -av or ver(Windows):

• Ubuntu: Linux compu.lan 5.15.0-56-generic # 62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
• macOS: Darwin j-macbookpro.lan 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64

List of programs I interact with

• iterm2 on macOS: Build 3.4.18
• wezterm on Ubuntu via flatpak: 20221119-145034
• w3m -version (same on linux and macOS): w3m version w3m/0.5.3+git20221221, options lang=en,m17n,image,color,ansi-color,mouse,menu,cookie,ssl,ssl-verify,external-uri-loader,w3mmailer,nntp,gopher,ipv6,alarm,mark (compiled with sixel support)

Please let me know if there's any other info that would be helpful. Thank you!

[imsnif]

Hey @jessebot - really glad you're happy with Zellij. What you mentioned sounds like a cool use-case, I hope to have more time to put in more cool multiplayer features in the future.

I was unfortunately not able to reproduce this. Using wezterm (I don't have access to a mac, so couldn't try with iterm2) with either bare img2sixel or even by cating the log file you attached, which means I'm getting the exact same bytes over the wire, ruling out application versions and the like.

I still want to solve this, so let's explore this further:

1. Does this happen every time, on every terminal emulator?
2. On startup and window size change, Zellij queries the terminal emulator for a pixel/cell ratio. If for some reason this query wasn't working properly, it could very much explain this problem (Zellij thinks the image is bigger than it actually is and doesn't map it properly to the viewport). From within Zellij, if you do echo -e "\033[16t", what do you get? If you quit zellij and do it again (making sure not to change font size or window size) do you get the same thing?

[jessebot]

Thank you for your quick followup! I got really busy with a project, so sorry for the delay in my response.

Update: This seems to be entirely related to iterm2, because when I try to reproduce it on the actual machine running Debian/Ubuntu with wezterm, not via SSH, but still in a zellij session, I can't reproduce it. Previously, when I was testing, I was SSHed into the Ubuntu machine from my mac in iterm2, but viewing the session on a monitor for Ubuntu, that was using wezterm as the terminal.

So this narrows it down to it being an iterm2 issue. What's weird is that I don't have this issue with most programs in iterm2, except two: zellij and neofetch (neofetch may be unsavable, but if you're curious, there it's because the window size is calculated with a program that isn't actually in the PATH by default)

From within Zellij, if you do echo -e "\033[16t", what do you get? If you quit zellij and do it again (making sure not to change font size or window size) do you get the same thing?

I tried this and it returns the same thing both times here when trying from within a zellij session:

# disabled powerline prompt for this b/c I wanted to test that it wasn't a weird powerline thing and it was not
jesse-macbookpro:~ jhitch$ echo -e "\033[16t"

^[[6;20;10tjesse-macbookpro:~ jhitch$ echo -e "\033[16t"

NOTE: the above is from iterm2 full screened on my mac locally and stty size still returns 43 143.

Is there anything else I can try to do here? I don't know rust, but I'm willing to try to learn if you can point me where to start taking a peak in zellij :)

[cloudymax]

Hoi 👋

Thanks for all your work on Zellij! It's been a real game-changer coming from using tmux/hyper to handle my multiplexing needs.

Looks like I'm also having this issue in Zellij on iterm2, I've taken some screenshots of the suggested actions:

In a Zellij Session:

Out of the session:

If there's any other testing that can be done to assist in debugging, please feel free to let me know 🙌

[imsnif]

Hey @jessebot - now it's my turn to apologize for the delay!

So, I have a guess - if you're willing to try and build Zellij from main and change some minor stuff?

Basically, I want to change these values: https://github.com/zellij-org/zellij/blob/main/zellij-server/src/os_input_output.rs#L53-L54 which are a different way for programs to query the pixel size of the (corresponding pty of the) window they're opened in.

I'd like to try and change them to the same values you'd get from this query echo -e "\033[14t". So the process should be:

1. Build Zellij from main and run it (there are some detailed instructions in here but I'm happy to also answer questions if you have any).
2. Perform this query inside a Zellij pane: echo -e "\033[14t"
3. Exit Zellij and enter these values hard-coded into the lines above (the first value in the response after [4; is the y size, the one after it the x.
4. Build Zellij again with these values and see if it solves the issue (make sure to use a pane of the same window and font size, since for the moment the values are hard-coded)

[jessebot]

Okay, I can try that today :) Also, don't apologize, I'm just happy we both try to eventually respond hahaha

Side note: I was in a senior devops engineer job interview yesterday (this was for a company that does ML work for satellite imagery). They asked me to do an (unplanned for) 5 minute demo of something I recently found cool (this was over Google meets), so I demoed zellij and they said "Wow, it's like discovering neovim after using vim forever!" and "This is cool! People in the office would definitely like to know about this." and it was a nice moment of high praise for zellij, and also honestly a really cool thing to demo. It was so nice to just say, "Sure, let me share my screen!" and then open a terminal, launch zellij, and start talking about the cool things it enables me to do when doing intensive kubernetes testing locally. I shined a spotlight on the easily adjustable sizing of panels (very useful for reading logs), intuitive tabs and renaming capabilities (very useful for labeling things for code demos!), floating panels (especially for putting things into the background temporarily, like an instance of the python interpreter to verify a python function, or tailing a k8s pod log), and the ability for others to join your session. It wasn't the best demo in the world, because I wasn't prepared, but it was still awesome to geek out with others about terminal multiplexers, and get some great feedback that I can also share with you and the other volunteers that make this project special :)

[imsnif]

That's very heartening to hear! Sounds like you did a cool job despite being put on the spot like that. Thanks for helping spread the word, and I hope you get the job (if you want it :))!

I might bug you in the future when I have to demonstrate the tool to DevOps people, since the last time I did any serious work in that space, Chef was all the rage :)

[jessebot]

Build Zellij from main and run it (there are some detailed instructions in here but I'm happy to also answer questions if you have any).

My mac is old and building zellij for the first time (I just installed rust) really made it sound like it was taking off for flight and took about 8 minutes but I did it. The load average on this macbook was at like 20 and it took 75%-80% CPU usage to get this done, but only initially!

After that, I was able to use cargo xtask run and run the echo command:

Then I modified file you mentioned:

git diff .
diff --git a/zellij-server/src/os_input_output.rs b/zellij-server/src/os_input_output.rs
index 07bd7c0f..ccb87f88 100644
--- a/zellij-server/src/os_input_output.rs
+++ b/zellij-server/src/os_input_output.rs
@@ -50,8 +50,8 @@ fn set_terminal_size_using_fd(fd: RawFd, columns: u16, rows: u16) {
     let winsize = Winsize {
         ws_col: columns,
         ws_row: rows,
-        ws_xpixel: 0,
-        ws_ypixel: 0,
+        ws_xpixel: 1400,
+        ws_ypixel: 760,
     };
     // TIOCGWINSZ is an u32, but the second argument to ioctl is u64 on
     // some platforms. When checked on Linux, clippy will complain about

Then I did a cargo xtask build again, this time in under 30 seconds, only takinga bit more time on zellij-server as we changed a value :).

Finally, I tested it again with cargo xtask run and unfortunately, it seems like it's still adding more padding to the bottom:

Happy to tweak anything else!

[imsnif]

Alright! Looks like we have no choice but to do this the hard way. :)

I'm going to ask you to have Zellij log all the render messages it sends to your terminal so that I can go through them manually and figure out what's going on here.

To do this, please add this line:

log::info!("output: {:?}", output.as_bytes());

above this line here: https://github.com/zellij-org/zellij/blob/main/zellij-client/src/lib.rs#L405

Then recreate the issue (with as few interactions with your terminal as possible so as not to inflate the log too much) and attach the contents of zellij.log (no need to attach the other files or to run Zellij with --debug) here.

Thanks!

[jessebot]

I'll get this done today! Thank you :)

[cloudymax]

EDIT: I was wrong, see jessebot's comment below

OLD TEXT: Looks like this issue was only reproducible when using iterm2. We switched to using wezterm on MacOS/Linux and are no-longer seeing this bug 🤷

[jessebot]

Yeah, sorry to take literally months to come back to this. I started a new job and was just really busy, but as @cloudymax mentioned, we've switched entirely to wezterm, where this isn't really an issue on either macOS or Debian Bookworm :)

EDIT: I spoke too soon. It still happens on shared sessions in zellij. Not sure if this is again because the session I'm connecting to is on Debian bookworm via SSH from macOS. Let me get you that log!

[cloudymax]

I have performed the steps requested to rebuild with the addition logging enabled and attached a video of myself re-creating the issue on a Debian12 amd64 host.

Also attached are the logs generated by both the standard and rebuilt executables.

Video: https://user-images.githubusercontent.com/84841307/226175132-c579adc4-1eb6-4063-a0bb-d8d2fe4e66d8.mov

Logs:

• zellij-additional-logging.log

• zellij-default.log

[midick]

I experience very similar issues. My terminal emulator is contour and while I don't get unnecessary padding, the image gets scaled weirdly and overhangs into the next lines: when clearing it persists:

I installed wezterm in order to see how things are over there and with this i get properly scaled images with large padding, just like jessebot.

[AlexKurisu]

Also on Wezterm sixel images that should be transparent for some reason aren't On Konsole sixel images are weirdly broken and still persist after clear

[midick]

Hi, is there any progress on this? I just checked again with the current version and on my end the behavior is still the same