Wezterm: ghostly text artifacts after clearing screen on macos with transparency enabled

[erf]

Describe the bug

When window_background_opacity is less than 1.0, e.g. 0.3, and i list some text in the terminal, then resize the window, sometimes the text (buffer?) is not cleared. I also noticed this some times when using the Kitty terminal some time ago. This might be an error with some macOS spesific code.

I noticed when i open Wezterm from the terminal i get this ERROR message, not sure if it has to do with anything but i thought i mention it.

% wezterm
 2020-10-28T09:25:59.204Z ERROR wezterm_gui::gui::termwindow > OpenGL initialized! ANGLE (Metal Renderer: Intel(R) Iris(TM) Plus Graphics 640) OpenGL ES 3.0.0 (ANGLE 2.1.0.8230df39a500) is_context_loss_possible=false
^C

Environment (please complete the following information):

• OS: macOS
• Version: 20200909-002054-4c9af461-240-g3808cf3f

To Reproduce

1. enable transparency by setting window_background_opacity=0.3
2. ls some text in the terminal window
3. resize the window, make it larger
4. now clear the window with Ctrl-L
5. notice the text is remained in the window, although with slight less opacity
6. resize the window again to make the text go away

Configuration

Only set window_background_opacity=0.3

Expected behavior

I would expect the text to always clear on Ctrl-L

Screenshots

[wez]

Seems to be specific to macOS. Neither Windows nor Linux have a similar issue.

This also appears whether Metal (via EGL) is used or the older CGL is used (you can use prefer_egl=false to force CGL if you want to compare this for yourself, but it appears the same).

[erf]

Did you manage to recreate it? Do you think it's worth looking into?

[wez]

Yeah, I can reproduce it. I'm not sure what can be done about it; wezterm does clear the sufaces (because otherwise we'd have the same problem on all systems, with or without opacity), so I'm not sure how to make macos properly respect that.
If kitty had the same problem, there may be evidence of an issue/PR over there (or in the underlying glfw library that it uses).

[erf]

Here are some issues which might be related (a couple added by me):

It might be a glfw issue on macOS, but not sure if you use it or create a macOS window "from scratch"?

..it seem you build it from scratch ?

https://github.com/kovidgoyal/kitty/issues/1207

https://github.com/kovidgoyal/kitty/issues/941

https://github.com/glfw/glfw/issues/1251

https://github.com/emoon/rust_minifb/issues/194

https://github.com/microsoft/vscode/issues/49438

[wez]

It seems like turning off the shadow effect around the window helps with this; I pushed a commit with that and would appreciate you feedback on whether it does the trick for you! While I didn't see the ghosting in that commit, I sometimes didn't see it without that change, so I don't know if I had a guaranteed repro or whether it really worked.

[wez]

May ultimately be this same root cause: https://stackoverflow.com/questions/20744936/drawing-to-transparent-destination-causes-drawing-artifacts/20746261#20746261 and the "best" fix may be to invalidate the shadow after a resize or whatever the trigger circumstance may be

[erf]

Sounds promising! Looking forward to try it. Do you know if it would be possible to trigger a new build after each commit, so we could test nightly faster?

[wez]

It does get built on each commit: you can download the mac build from that commit here: https://github.com/wez/wezterm/runs/1323247067

[wez]

(dark mode screenshots due to Dark Reader browser extension!)

[wez]

You can then click on the artifacts on the build page:

[erf]

Great, maybe you could add that link to the web page (if it's not there). Do you know when it's available on brew?

[wez]

the "nightly" download will update within the next hour, if that last build didn't already pick it up:
https://github.com/wez/wezterm/actions?query=workflow%3Amacos_continuous
Once it is in the nightly, you can do a brew rm wezterm ; brew install --HEAD wezterm to pick it up.

[erf]

I think that fixed it! No more ghosts! Nice!

[erf]

Doing that resizing, reminded me off the #138 issue. If you can fix that, your terminal is in my humble opinion superior to all other terminals!

[wez]

I pushed an alternative resolution that should let us keep the default shadow. Seemed to work for me with limited testing. If that doesn't also work for you we can always go back to turning off the shadow.

[erf]

Cool, will check it out once the build is ready. Btw, not sure, but there might be a slight performance increase with shadows off and a cleaner look..? Maybe make it an setting?

[erf]

Ok, i've tested the latest version now, and i only saw the ghost effect a couple of times and then it went away fast as i started typing ..but it did seem ALOT more slugish the the previous version and does some weird text scaling stuff when resizing.

I did a comparison between the previous no-shadows version and the latest and the no-shadows version is ALOT faster when resizing and in general use. I would much prefer the no-shadow version.

[wez]

OK, that's sold me. I'll revert that last commit a little later this evening.