search

zellij-org / zellij

A terminal workspace with batteries included
https://zellij.dev
MIT License
20.89k stars 638 forks source link

sixels printed inside terminal emulator does not get cleared #3173

Open shadow-absorber opened 7 months ago

shadow-absorber commented 7 months ago

1. Graphical issue inside a terminal pane (eg. something does not look as it should)

  1. Delete the contents of /tmp/zellij-1000/zellij-log, ie with cd /tmp/zellij-1000/ and rm -fr zellij-log/ (/tmp/ is $TMPDIR/ on OSX)
  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)

Please attach the files that were created in /tmp/zellij-1000/zellij-log/ to the extent you are comfortable with.

Basic information

zellij --version: zellij 0.39.2

stty size: 52 208

uname -av or ver(Windows): Linux sam-computer 6.7.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:31:48 +0000 x86_64 GNU/Linux

Further information

Reproduction steps, noticeable behavior, related issues, etc

after running img2sixel /path/to/png.png and then running the clear command the image does not get cleared from the screen this is in the alacritty graphics branch that is working flawlessly outside of zellij

zellij.log

shadow-absorber commented 7 months ago

just tested with xterm too and same issue with sixels not getting cleared when running clear command

manueldeprada commented 2 months ago

As @Zettexe pointed out in #3372 , this is probably a consequence of sixel images being rendered with twice the height they should. Example:

image

link to the test image

lypanov commented 2 months ago

As @Zettexe pointed out in #3372 , this is probably a consequence of sixel images being rendered with twice the height they should. Example:

image

link to the test image

Nice test case. I'll look into this issue next as it's breaking my sixel based workflow.

manueldeprada commented 2 months ago

Weirdly enough, I recently switched to a branch of Alacritty with sixel support and there zellij's sixel are correct...

image

next week I got some time, I will investigate

lypanov commented 2 months ago

This may be the key - foot supports aspect ratios and defaults to 2:1. I'll look into this part of the zellij code this coming week.

On Sat, Jul 20, 2024, at 21:12, Manuel de Prada Corral wrote:

Weirdly enough, I recently switched to a branch of Alacritty with sixel support https://github.com/alacritty/alacritty/pull/4763 and there zellij's sixel are correct...

image.png (view on web) https://github.com/user-attachments/assets/3aa357f8-9ae5-459d-97b1-c38c5cdbd7a4

next week I got some time, I will investigate

— Reply to this email directly, view it on GitHub https://github.com/zellij-org/zellij/issues/3173#issuecomment-2241265469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAACN4JNHXVQUH6IXLVJ7DZNKZDVAVCNFSM6AAAAABEAWJTWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGI3DKNBWHE. You are receiving this because you commented.Message ID: @.***>

lypanov commented 2 months ago

Yeah that's it, I was able to use wezterm record to show that zellij is not passing through the raster attributes needed to fix the default 2:1 ratio (spec default) that foot uses and other terminal emulators fail to correctly default to. Comment from Aram on the line in question: // we ignore pan/pad because (reportedly) no-one uses them. Alas some emulators are trying to get to spec on this. I'll look into writing a patch to pass this through from the tokenizer.

lypanov commented 2 months ago

Okay verified the theory by hacking sixel-image to always spew a hardcoded override to 1:1 ratio. Foot now renders your test case correctly. Next up will be to understand enough of the spec to add pan/pad roundtripping and understand how that fits into Aram's concerns.

image