[Linux] Graphical artifacts when switching workplaces in i3wm

[valters-tomsons]

https://github.com/FaithLV/spectabis-next/issues/5

Using i3wm (i3-gaps).

Launch a GUI window, switch to another workspace and after couple of seconds switch back to the window workspace.

Window will appear fully transparent, artifacted or will display previous application for a few seconds.

Doesn't happen when using Windows 10 workspaces.

Screenshots: https://imgur.com/a/KcS2MGa

[kekekeks]

Does i3 use compositing?

[kekekeks]

Also try monitoring messages sent to the window on workspace switch (xwininfo will give you an id that could be then passed to xev -id <id>. If your WM doesn't use compositing, the window should be getting Expose events

[valters-tomsons]

No, i3 by itself doesn't do compositing. I use picom for that. Nevertheless, the issue persists with compositor running or not.

When the window is artifacted, I'm seeing a lot of FocusOut events, even thought the window is focused. I might be wrong here because I'm not sure what I'm exactly looking for. (Not seeing any Expose events)

When I switch to window's workspace, I do see

VisibilityNotify event, serial 24, synthetic NO, window 0x6a000ee,
    state VisibilityUnobscured

[kekekeks]

Mkay, we might want to handle VisibilityUnobscured and VisibilityPartiallyObscured in the same way as Expose and trigger a redraw, I guess.

[johannlejeune]

Hi, I saw that you implemented what you were talking about in commit https://github.com/AvaloniaUI/Avalonia/commit/ef9bb42252601e50dd55de32b212115f1953474b, so I tried switching to 0.10.0-preview5 to test if it fixed the issue. Unfortunately, the issue is still present. It looks like it sometimes gets repainted, and sometimes not, but I'm not sure. I'd want to debug the whole thing and see if it actually asks for a repaint, but I don't know yet how I could do this, so sorry if I can't give any leads for a potential solution. :confused:

[kekekeks]

I'd want to debug the whole thing and see if it actually asks for a repaint, but I don't know yet how I could do this

Running ControlCatalog.NetCore project from a cloned Avalonia solution should just work.

[johannlejeune]

@kekekeks Thanks for the tip ! I was able to run it and debug it. I can confirm that DoPaint gets called every time I switch back on the workspace containing the window. However, even after it gets called, it sometimes still artifacts for some reason. When this happens, the next time a repaint is triggered (for example, when hovering on a list item), the artifacts disappear. So for the sake of science, I tried giving it a lower priority (DispatcherPriority.SystemIdle), no luck. I also tried to duplicate the DoPaint call so it gets called twice each time, and that did the trick. When calling DoPaint twice, there are no artifacts anymore. So yeah, I can't say why this happens, maybe some sort of race condition where the repaint is done before the workspace is rendered by i3, and calling DoPaint twice introduces enough overhead to make the second repaint happen after i3 rendered the workspace ? Hope this gives some more information to find a sustainable solution !

PS : If it is of any help, I don't have any compositor, it's just i3, maybe your initial fix will be enough for users with a compositor.

[kekekeks]

Try enabling window compositing by running compton alongside with i3

[johannlejeune]

Well, that was unexpected. I tried enabling picom (which is a fork of compton) and was pretty sure that would fix the artifacts. Turns out it doesn't. I was still able to reproduce the issue pretty easily by just going back and forth between two workspaces. Calling DoPaint twice still produces better results overall, but doesn't completely eliminate the artifacts if I really try hard enough.

[valters-tomsons]

0.10.0 seems to have fixed all graphical issues related to this topic. :heart: