Rendering appears to be slow

[sayanarijit]

Hi, I was evaluating Wezterm as well as some other terminals as potential options to switch from Alacritty after an unfortunate set back.

As you can see in this video, Kitty and Konsole seems to be rendering fine, while Alacritty is having some issue.

I performed the same test using Wezterm, and it appears to be rendering slow as well.

I don't think I'm doing something specifically wrong as I'm running the applications without tweaking them or intentionally trying to make slower/faster.

So my question is, does this issue look like something that can be easily fixed?

Here is the script I'm running.

Please note that I prefer to test real-world scenarios instead of using repo provided benchmarks as they are often biased.

[wez]

While I don't agree with the tone of the response you encountered in the linked issue, I do agree that it appears to be a synchronization issue.

wezterm is repainting the screen several times per frame; the initial clear screen triggers a paint so that is a brief black flash, and you can see the cursor moving through various positions as cat outputs the lines and they get rendered.

The other thing that makes the display look worse is that the height of the terminal in your video is shorter than the number of lines in the output, so the terminal is scrolling the display, which adds to the visual noise. Use ctrl-shift-- a couple of times to reduce the font size until the frames fit both height-wise and width-wise in the terminal.

Can this be "fixed"? It's a balance: wezterm tries to show you things with the lowest latency as they change. What you want in this case is to artificially increase the latency in processes to avoid seeing the intermediate states. While that's desirable in this case, if it was always that way the whole terminal experience would feel laggy--you don't want your interactive text input situation to be high latency.

I recently did some work for #740 that improves draw performance for wide terminals that might help your experience with this (you'll need to be running a nightly build for those changes), but both your test and the case in that issue are pathological terminal output scenarios: a lot of wide textual output is difficult to process in a short amount of time, and the terminal is optimized for low latency interactive use, rather than dumping bulk output.

There's a draft spec that discusses a way for an application to be explicit about synchronizing frames, but it doesn't have a lot of traction: no applications implement it AFAICT.

The iTerm2 terminal emulator has an option to defer painting while the cursor is hidden, which can make big screen updates in eg: vim look better. I have experimented with that heuristic in wezterm, but I didn't find that it helped very much, and in any case, your test scenario doesn't hide the cursor.

Now, if you want to watch actual video in the terminal, wezterm has one of the better (perhaps even best?) implementations for processing actual image streams as both sixel and iTerm2 image protocol graphics; https://github.com/hzeller/timg/ is a convenient tool for re-encoding images and videos into the terminal.