Visual problems with xwayland

[dbrgn]

Thanks for your patch, in general it seems to work nicely (even accelerated WebGL)!

When using xwayland applications, I regularly get the entire application window filled with what appears to be a garbage buffer, or something like that.

https://user-images.githubusercontent.com/105168/116798345-bc1eb700-aaee-11eb-8412-0547600d82af.mp4

I'm on Arch Linux with a GTX 760.

Versions:

• sway 1.6-7c74f01f (May 1 2021, branch 'master')
• wlroots-eglstreams: Current master

Is this something that can be fixed? Let me know if I can help somehow.

[danvd]

@dbrgn I'll try (have the same issue), hope the problem in the patch, not in something like mesa etc.

[danvd]

The reason: image producer (in our case image == app's window, producer == xwayland) can run in starvation and not supply its window picture in time. In that case we get flicker/garbage. There were 2 variants for fixing: 1) Lightweight. Reuse old produced frame by means of EGLStreams (yes, it can do that). 2) Heavy. Copy acquired image into separate texture and use that until next new image is available

I made corrections and the first variant is used now. @dbrgn could you please check? For me it solved the issue.

If something nasty happens, the log will contain the following records:

New EGLStream frame is missing for currently attached stream!

[dbrgn]

So far so good! Really cool, I can finally use Sway on my old nVidia card 🙂 Thank you @danvd for the patch and the fix.

If something nasty happens, the log will contain the following records:

That log would be sent to stdout after starting sway, right?

[danvd]

Yes, this record will have ERROR level.

[dbrgn]

Something I noticed when working with alacritty on xwayland: Sometimes after pressing a key, nothing happens. Then after pressing another key, both key inputs are shown on the screen.

I assume this is because the starvation issue happens after the first key input, and then because of the buffer re-use the updated screen contents are never used, until another event happens that updates the buffers. Could that be the case?

(It's still better than the garbage that was displayed previously, but it feels quite laggy. I wonder whether there's a solution / workaround for this.)

[danvd]

Not sure that such behavior can be fixed nicely - looks like xwayland, which is using software GL layer, just can't produce some frames in time. Could you please make a test with kde and gnome also? How do they cope with that?

One workaround that I see is to force render a window if old frame was used (or try to fetch a frame several times until a new one is arrived), but it looks like a temporary fix.

There are 2 variants as of now: use termite or kitty (they both do work in native wayland mode) or wait until nvidia releases 470 driver with accelerated xwayland support.

[dbrgn]

I don't currently have a gnome installation, but I could set it up sometimes.

Yeah, those workarounds (another terminal, or waiting for the new driver) are all fine 🙂 It's just that using an xwayland terminal made the problems visible (whereas with video, for example, you'd probably just get a very slight frame delay), so I thought I'd report it.

[danvd]

@dbrgn I just committed code that does stream flush like described in this commit: https://gitlab.freedesktop.org/xorg/xserver/-/commit/7515c23a416825f0db51f9b445279b12d5918ebf

Please check if it solves stale image issue

[dbrgn]

@danvd great, thank you, I'll test it!

[dbrgn]

Hm, with the new 0.12.0.r538.g8ba4a931 version (as opposed to the previous 0.12.0.r518.g42d5ba18 version) sway crashes on start. I'll try to find out what's happening tomorrow 🙂

[danvd]

It's because of undefined symbol (wlroots changes its abi frequently). git pull and reinstall helps. (But maybe you have another issue)

[dbrgn]

You're right, I missed that.

Seems to be much better so far! 🎉 This issue can probably be closed now.

[danvd]

Great :)