ghostly text artifacts after clearing screen on macos with transparency enabled #310

erf · 2020-10-28T09:52:59Z

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

enable transparency by setting window_background_opacity=0.3
ls some text in the terminal window
resize the window, make it larger
now clear the window with Ctrl-L
notice the text is remained in the window, although with slight less opacity
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

The text was updated successfully, but these errors were encountered:

wez · 2020-10-28T16:50:57Z

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 · 2020-10-28T17:05:17Z

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

wez · 2020-10-28T17:12:21Z

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 · 2020-10-28T17:57:22Z

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 ?

kovidgoyal/kitty#1207

kovidgoyal/kitty#941

glfw/glfw#1251

emoon/rust_minifb#194

microsoft/vscode#49438

Not 100% sure that this is it, but it seems much less likely that artifacts will appear in conjunction with transparency when the window shadow effect is disabled; I didn't see the ghosting with this disabled, but I sometimes dididn't see it with it enabled, so I'm not sure that we have a 100% reliable reproduction, and thus am not sure that this is a fix. I found mention of disabling the shadow in some example code on stackoverflow when I was first researching this, but it wasn't supplied with an explanation. Perhaps this is why? Longer term we might want to be smarter about turning off the shadow only when the opacity is != 1.0, but at the moment the window layer can't see the config, so let's just default it off for the moment until we see if it does the trick. refs: #310

wez · 2020-10-28T21:16:05Z

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 · 2020-10-28T21:20:41Z

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 · 2020-10-28T21:36:32Z

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 · 2020-10-28T21:45:23Z

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 · 2020-10-28T21:46:03Z

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

wez · 2020-10-28T21:47:15Z

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

erf · 2020-10-28T22:02:45Z

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 · 2020-10-28T22:06:39Z

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 · 2020-10-28T22:07:48Z

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

erf · 2020-10-28T22:10:26Z

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!

This one invalidates the shadow when we invalidate the window, so we should get to keep the shadow and lose the ghosts. refs: #310

wez · 2020-10-28T23:10:04Z

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 · 2020-10-28T23:23:58Z

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 · 2020-10-29T00:41:06Z

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 · 2020-10-29T00:46:54Z

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

This reverts commit f2b504e; we prefer the overall snappier perf from not having a shadow. refs: #310

fanzeyi · 2021-01-30T02:49:57Z

it is a little bothering me that WezTerm doesn't give me a drop shadow for the Window. Would it be okay if I make it only disable shadow when transparency is set to non 1.0?

Evidence: * #310 (comment) * #2669 (comment) * #2669 (comment) seems to suggest that window shadows hurt performance, so add a way to disable them independently from window opacity. You may use: ``` config.window_decorations = "TITLE|RESIZE|MACOS_FORCE_DISABLE_SHADOW" ``` for this. refs: #2669

github-actions · 2023-02-04T18:02:15Z

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.

erf added the bug Something isn't working label Oct 28, 2020

erf changed the title ~~Buffer text hangs after it should be cleared~~ Buffer text hangs after it should be cleared ( with transparency enabled ) Oct 28, 2020

erf changed the title ~~Buffer text hangs after it should be cleared ( with transparency enabled )~~ Text hangs after it should be cleared ( with transparency enabled ) Oct 28, 2020

wez added the macOS Issue applies to Apple macOS label Oct 28, 2020

wez changed the title ~~Text hangs after it should be cleared ( with transparency enabled )~~ ghostly text artifacts after clearing screen on macos with transparency enabled Oct 28, 2020

erf closed this as completed Oct 28, 2020

wez added a commit that referenced this issue Oct 28, 2020

window: alternative shadow/ghost/macos fix

f2b504e

This one invalidates the shadow when we invalidate the window, so we should get to keep the shadow and lose the ghosts. refs: #310

wez added a commit that referenced this issue Oct 29, 2020

Revert "window: alternative shadow/ghost/macos fix"

92bdc4a

This reverts commit f2b504e; we prefer the overall snappier perf from not having a shadow. refs: #310

fanzeyi mentioned this issue Jan 30, 2021

Only disable drop shadow on macOS when window background opacity is transparent #445

Merged

wez mentioned this issue Feb 1, 2023

Lag when switching between Stage manager tasks (macOS Ventura) #2669

Open

github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ghostly text artifacts after clearing screen on macos with transparency enabled #310

ghostly text artifacts after clearing screen on macos with transparency enabled #310

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020 •

edited

Loading

wez commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

wez commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

erf commented Oct 29, 2020

wez commented Oct 29, 2020

fanzeyi commented Jan 30, 2021

github-actions bot commented Feb 4, 2023

ghostly text artifacts after clearing screen on macos with transparency enabled #310

ghostly text artifacts after clearing screen on macos with transparency enabled #310

Comments

erf commented Oct 28, 2020

Describe the bug

Environment (please complete the following information):

To Reproduce

Configuration

Expected behavior

Screenshots

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020 • edited Loading

wez commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

wez commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

erf commented Oct 28, 2020

wez commented Oct 28, 2020

erf commented Oct 28, 2020

erf commented Oct 29, 2020

wez commented Oct 29, 2020

fanzeyi commented Jan 30, 2021

github-actions bot commented Feb 4, 2023

erf commented Oct 28, 2020 •

edited

Loading