Some TUI will flash all the time

[asorander]

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

Linux X11

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

Gnome 42.3 + Mutter

WezTerm version

20220807-113146-c2fee766

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

Some TUIs will flash whenever there is something changing on the screen. In the video below, I show a comparison between the same apps (Ncspot and the clock on ncmpcpp) running on Wezterm and Gnome Terminal, and the "flashing" isn't happening on Gnome Terminal. Also, it doesn't happen on Alacritty, so i don't think it's some gpu issue.

2022-08-21.16-07-36.mp4

To Reproduce

Just browse a list of musics on ncspot or open the clock on ncmpcpp.

Configuration

It also happens without a custom config file.

Expected Behavior

Do not flash on TUIs.

Logs

Debug Overlay
wezterm version: 20220807-113146-c2fee766
OpenGL version: NVIDIA GeForce GTX 1660/PCIe/SSE2 4.6.0 NVIDIA 515.65.01
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
16:27:30.163 WARN wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015))

Anything else?

No response

[wez]

Please capture a terminal recording:

• Launch wezterm. If possible, please use 80x24 for the terminal dimensions as it helps to keep things smaller and easier to manage.
• Inside that terminal run wezterm record to start a recording session.
• Run through your reproduction steps
• Then type exit
• You should see a message like:

*** Finished recording to /var/tmp/wezterm-recording-sF6B3u.cast.txt

• Attach the file that it produced to this issue.

The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using wezterm replay.

The terminal recording allows me to replicate what is being sent to the terminal without requiring me to install the same applications as you and replicate your configuration for everything.

[asorander]

Please capture a terminal recording:

* Launch wezterm.  If possible, please use 80x24 for the terminal dimensions as it helps to keep things smaller and easier to manage.

* Inside that terminal run `wezterm record` to start a recording session.

* Run through your reproduction steps

* Then type `exit`

* You should see a message like:

*** Finished recording to /var/tmp/wezterm-recording-sF6B3u.cast.txt

* Attach the file that it produced to this issue.

The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using wezterm replay.

The terminal recording allows me to replicate what is being sent to the terminal without requiring me to install the same applications as you and replicate your configuration for everything.

Here's the output:

wezterm-recording-UBGaJu.cast.txt

This time I cleared my config file, leaving only the following lines:

local wezterm = require 'wezterm'
return {
  initial_rows = 24,
  initial_cols = 80,
}

[wez]

What's happening here is that both of those programs are very poorly optimized when it comes to what they output; they are erasing a screen line by line before repainting the lines individually and in some cases, re-erasing the lines again before repainting them.

Because they output a fairly large chunk of redundant output at a time, and that data doesn't fit in a single buffer write, wezterm ends up painting the screen in between "logical" frames from the perspective of the application.

Ideally those programs would implement https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036 to explicitly indicate when they writing out the screen.

I can add some artificial latency in wezterm to increase the chances of recognizing those as a batch, but it will harm the performance of things like time cat bigfile "benchmarks". I will put that behind a configuration setting so that the degree of additional latency can be tuned.

[asorander]

Oh, I see. I hope that they fix this kind of issue in the future on those apps...
Thank you very much for your time and for taking a look at it! :)

[wez]

This should be fixed now in main.

It typically takes about an hour before fixes are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[asorander]

Just tried the nightly AppImage, and now it's working perfectly! No more issues in any app that I've tested. :)

Thank you very much!

[github-actions]

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.