Kitty graphics protocol horribly non-conformant

wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

https://wezfurlong.org/wezterm/

Other

17.49k stars 787 forks source link

Kitty graphics protocol horribly non-conformant #3817

Closed ctrlcctrlv closed 1 year ago

ctrlcctrlv commented 1 year ago

What Operating System(s) are you seeing this problem on?

Linux X11, Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

KDE

WezTerm version

wezterm 20230408-112425-69ae8472

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

https://github.com/kovidgoyal/kitty/discussions/6331

To Reproduce

No response

Configuration

no config

Expected Behavior

exact same output as kitty or close to it

Logs

No response

Anything else?

No response

wez commented 1 year ago

To use your own offensively uncharitable phrasing, this issue is horribly incomplete.

It's lacking concrete, actionable descriptions of individual conformance concerns; it's just a link to a video with no description of expected vs. actual behavior.

It seems possible or likely that you haven't checked to see if the existing open issues here about kitty protocol issues are duplicates of, or overlap with, the vaguely reported concern.

Please make another pass to flesh out this issue.

ctrlcctrlv commented 1 year ago

yes ok. i did not mean to offend, just to state the problem. i would not be doing this work if i did not want to increase harmony / conformity between implementations, so offending u is not my goal. :)

ctrlcctrlv commented 1 year ago

As I see it, these are the issues in the first conformance test (the original issue includes a typescript replayable on any system with util-linux)—

New lines can overwrite graphics which ought to be above them. This is because they are drawn as black and not alpha, I think.
WezTerm's implementation does not handle the background/foreground color protocol distinction. This is why the right text alternates between fore and back color on/off, to show this.
The compositing is wrong.

wez commented 1 year ago

I'd appreciate it if you could split this into 3 different issues, each with an ideally minimal, but otherwise small reproducing script, and an explanation of what the conformant behavior should be and where the deviation is. That will help a great deal in making sure that the root causes are addressed.

I don't have sufficient time to review and compare a large suite of tests, especially if there isn't a programmatic pass/fail indication, so anything you can do to firmly point me at the deviations will help nail this.

Thanks!

ctrlcctrlv commented 1 year ago

🫡 will do

github-actions[bot] commented 1 year ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.