Window is visually empty until there is activity on elements in Wayland

[xbt573]

Best way to describe this issue is to look at image.

Window appears as empty until there is some interaction with elements (buttons, text inputs) in this window.
This issue only reproduces in Wayland environments (Works with WAYLAND_DISPLAY unset, XWayland).

See also: ZDoom/gzdoom#2712

[itaranto]

I'm having the same issue here.

I'm using Sway on Arch Linux. I'm using this AUR package.

[Peppersawce]

I don't know if this counts as the same bug, but I'm experiencing something very similar on Haiku, where ZWidget should run on SDL only, so no Wayland-related code is used:

Interacting with invisible elements doesn't make the window display in this case, but clicking inside the window does seem to help speed the window being displayed somewhat (?)

This is how they're displayed after waiting a bunch.

EDIT: Issue is also present when using this repo's source

[Kithop]

Same issue here with their launcher when compiling uzdoom 4.14.3 today, either from the AUR or manually - however, their .AppImage works fine. With the self-compiled version, it seems to not render anything until I mouse over a tab or button that has some kind of rollover UI feedback (highlighting).

I suspect this might also be the "takes a bunch of seconds to start displaying window content" mentioned: UZDoom/UZDoom#260 (comment)

Not sure if this could be related to having SDL3 also present, or if this is something to do with their included copy of ZWidget not being in-sync here.

[Peppersawce]

Same issue here with their launcher when compiling uzdoom 4.14.3 today

To be fair, 4.14.3 uses an older version of ZWidget, which is the one I tested when commenting in the post above yours. (more or less)

The newer ZWidget that's currently used in UZDoom's trunk performs better (but still takes a bit of time for me on Haiku), it might even fix the issue for you.

In other words, try compiling UZDoom from trunk instead, that might fix it for you.

I suspect this might also be the "takes a bunch of seconds to start displaying window content" mentioned

Yeah, sort of. With that sentence I'm actually referring to the newer ZWidget, I would describe how the old one performs (in my experience on an obscure OS) less charitably.

[dpjudas]

ZWidget includes three backends that can do wayland: SDL2, SDL3 and its native Wayland backend.

Apps (UZDoom) got two options. They can make zwidget choose by calling DisplayBackend::TryCreateBackend(), or they can explicitly ask for a specific backend by calling DisplayBackend::TryCreateSDL2(), DisplayBackend::TryCreateSDL3() or DisplayBackend::TryCreateWayland(). So first thing to identify here is which backend is in use when this manifests itself.

I can't test anything wayland related myself as my Linux Mint's wayland support is too unstable for me to do anything. But it would be interesting to know which backend is in use since the SDL2 backend always worked fine for me. But of course that's with SDL2 using X11. Also try to make sure this is using the master version of zwidget - otherwise it could be an issue that has already been addressed.

There's also a minor API change between current zwidget and what GZDoom is using. The resource loading may have to be adjusted in UZDoom, unless that's already been done with the version they use now. There is now a ResourceLoader interface that needs to be implemented that used to be two global functions apps had to implement before.

[Kithop]

The newer ZWidget that's currently used in UZDoom's trunk performs better (but still takes a bit of time for me on Haiku), it might even fix the issue for you.

In other words, try compiling UZDoom from trunk instead, that might fix it for you.

Yup - can confirm, building the trunk version works much better, and doesn't seem to have the Wayland issue any more on my end, so between the two teams I'm guessing this can be closed as resolved - thanks for clarifying!

[Peppersawce]

But it would be interesting to know which backend is in use since the SDL2 backend always worked fine for me. But of course that's with SDL2 using X11.

For reference, on Haiku it should run on base SDL2 as far as I can remember from testing.

Terminal output and how it looks on SDL2 2.30.10 here, using UZDoom compiled from trunk.

It takes some seconds to load but it's much less impactful than before.
The issue is for Wayland though so it's technically resolved.

[Kithop]

Apps (UZDoom) got two options. They can make zwidget choose by calling DisplayBackend::TryCreateBackend(), or they can explicitly ask for a specific backend by calling DisplayBackend::TryCreateSDL2(), DisplayBackend::TryCreateSDL3() or DisplayBackend::TryCreateWayland(). So first thing to identify here is which backend is in use when this manifests itself.

For what it's worth, too, it looks like they're currently using TryCreateWin32() first, and if that fails, TryCreateSDL2() only: https://github.com/UZDoom/UZDoom/blob/149573fcad2b4d4a94deeb89dfef33d1122d9a10/src/d_main.cpp#L4181

But, someone has a PR draft open for switching to SDL3, including TryCreateSDL3(): https://github.com/UZDoom/UZDoom/pull/470/files#diff-8c64311b61cfa9dabff5554a3bd56ce4d644af58e71af772376594a78f872663

I figure if they're using SDL for other things already, there's probably no point suggesting TryCreateWayland() explicitly, but if the generic TryCreateBackend() should work, now, that might save them the initial TryCreateWin32() call as well?

It takes some seconds to load but it's much less impactful than before.

Actually, I do notice this, but it's about ~3 seconds between startup and the initial launcher window popping up, pretty consistently. Not a major issue for me, but just in case this is indicative of anything interesting.

[dpjudas]

For what it's worth, too, it looks like they're currently using TryCreateWin32() first, and if that fails, TryCreateSDL2() only

OK so its still done the way it was introduced in VKDoom (VKD -> GZD -> UZD). The logic behind this choice is that on Windows, the win32 backend is desired. On Linux, it wants to use SDL.

The X11 and Wayland backends are a lot newer and less battle tested. At the time it wasn't worth the risk enabling them versus always relying on SDL - that's why they don't use TryCreateBackend().

Actually, I do notice this, but it's about ~3 seconds between startup and the initial launcher window popping up, pretty consistently. Not a major issue for me, but just in case this is indicative of anything interesting.

I don't think that is caused by zwidget. Last time I looked at start up time (in VKDoom, but its the same code in UZD), its was the wildcard matching code when identifying wads that was really slow - especially in debug builds. It was only annoying me in debug builds, and everyone else didn't seem to care at all on Discord, so I didn't try to do anything about it as I had not written that code.