Editor window resizing on Wayland doesn't work (GNOME with tiled window)

[gregcsokas]

Tested versions

• Reproducible in: 4.3-beta3
• Not reproducible in: 4.3-beta2

System information

Fedora 40 - Godot 4.3-beta3 (custom built 64 bit with c# enabled)- Vulkan (forward +) - Wayland - AMD Ryzen™ 7 6800HS with Radeon™ Graphics × 16

Issue description

A bunch of platform/linuxbsd/wayland/wayland_thread.cpp:2053 - Parameter "ws" is null. message appears in the editor output, and I cannot resize the editor window anymore. I don't know what else is broken, I'm still testing, but this "feature" :smile: arrived with pr #94021.

Steps to reproduce

I just compiled a custom version from the fresh Godot 4.3-beta3, and starting the editor the problem appeared. This issue also appeared on the released binaries.

Minimal reproduction project (MRP)

I don't know if this thing appears on Ubuntu or other Linux distribution. But on Fedora 40 (workstation) just download the binary from Godot builds.

[Riteo]

Thanks for your report!

The error you're seeing, while still a bug, isn't related to the (in)ability to resize the window, so the issue must be somewhere else.

Wayland compositors come in all shape and sizes, so it's quite hard to know what's going on here without some more information. Could you please tell me more about your setup, like what compositor you're using and what version is it?

A full verbose log with WAYLAND_DEBUG=1 will help tremendously too. Could you take one? The command should look something like this: WAYLAND_DEBUG=1 ./my-godot-executable --verbose > wayland-debug.log 2>&1.

[gregcsokas]

Thanks for the verbose log stuff wayland-debug.log

btw you are right, that's not related to resizing, but since the previous version, I lost the ability to resize the window too :)

[Riteo]

I just tried the latest beta release in a Fedora 40 workstation live ISO. The error popped up indeed (it's fixed in master!) but I can't replicate the inability to resize :(

Could you please describe you setup further? In the log I can see multiple displays getting registered, including an embedded one, so I suppose you're using a laptop docked? Some screens look HiDPI, are you scaling the editor interface?

My current theory is that this might be scaling related, as the minimum window size is scaled with the UI. You could try using a single screen or using the 100% editor scale (if it isn't already the case).

[gregcsokas]

Sorry for the different language but here are some screenshots of my screen settings, there is no scaling on any screen ( Here is a dictionary for the screenshots )

{
  "Tájolás": "orientation",
  "Felbontás": "resolution",
  "Frissítési gyakoriság": "Refresh rate",
  "Méretezés": "scaling"
}

[Riteo]

@gregcsokas it's also possible to change Godot's scale itself in the editor or project manager settings. Could you also check what scale is set there?

[gregcsokas]

Sure, here is the beta-3 And this is beta-2

[Riteo]

@gregcsokas uh, interesting. Wayland isn't enabled in beta 2. You can tell that because it's fully multi-windowed (we still don't support that for a few reasons, WIP and all that). Could you try going into the editor settings and turn on "prefer wayland" and see if the issue persists?

Edit: I'm talking about beta 2, to make sure that it isn't a new thing.

[gregcsokas]

This is the two editor window-related settings next to each other and the multi-window settings

As you see one of the windows has a blueish "header" I can move out that window from the editor, that's beta-2, but the beta-3 is completely themed and I cannot move out the settings window from the editor. but As I see the settings are the same.

Edit: Wayland settings:

[Riteo]

@gregcsokas weird. I think the wayland backend is failing to start altogether. Could you check the verbose logs(run the project manager with --verbose flag)?

Edit: the fact that it now works in beta 3 might be related to #92663. Edit2: if I recall correctly, that is, I'm not sure which release it got into.

[gregcsokas]

For comparison, I did it with both versions. wayland-debug-beta-2.log wayland-debug-beta-3.log

[gregcsokas]

Okay, I'm not familiar with this log but I'm sure beta-2 is not wayland :D

[Riteo]

@gregcsokas Yeah, your beta2 just... Ignores everything. I am quite confused right now. Since it's a custom build perhaps it didn't build the wayland backend at all in beta 2?

I'm sorry for all this back-and-forth, could send me the result of godot with --help (should list the availble backends) and try to replicate this issue in an official beta2 release, which hopefully has wayland built-in?

[gregcsokas]

I think you are completly right about my beta-2 build.

Here is the beta-3 --display-driver <driver> R Display driver (and rendering driver) ["x11" ("vulkan", "opengl3", "opengl3_es"), "wayland" ("vulkan", "opengl3", "opengl3_es"), "headless" ("dummy")].

and the beta-2 --display-driver <driver> R Display driver (and rendering driver) ["x11" ("vulkan", "opengl3", "opengl3_es"), "headless" ("dummy")].

Okay, I started building a new beta-2 :D

[Riteo]

@gregcsokas yay! BTW, I'm quite sure I know what happened there: if the build script doesn't find wayland-scanner it disables the backend, prints a warning and keeps going. Thing is it just zips from the screen as everything builds and nobody notices it unfortunately.

I'm not sure how to improve the UX there lol.

[gregcsokas]

probably, because these lines are not familiar from the time when I built my beta-2, my biggest fear is that, after this build, beta-2 won't work properly too :D

[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/fractional_scale.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/idle_inhibit.gen.h"
Generating Wayland client header: "platform/linuxbsd/wayland/protocol/pointer_constraints.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/pointer_gestures.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/primary_selection.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/relative_pointer.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/tablet.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/text_input.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/viewporter.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/wayland.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/xdg_activation.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/xdg_decoration.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/xdg_foreign.gen.h"
[  2%] Generating Wayland client header: "platform/linuxbsd/wayland/protocol/xdg_shell.gen.h"

[gregcsokas]

BTW I just forget to mention that when I'm trying to resize the window, in the log file (the first wayland log) has this "event" Pointing window. I don't know is it related or not, but this is what happening in that moment.

[Riteo]

@gregcsokas

probably, because these lines are not familiar from the time when I built my beta-2, my biggest fear is that, after this build, beta-2 won't work properly too :D

considering that there's very little left to debug, that'd be a lead and thus a good thing at this point xD

If it happens on beta-2 too, I'm quite sure that this must be related to your specific software/hardware setup in one way or another.

Wait, I've never seen a full screenshot of you running the Wayland editor. Do you see any form of decoration on the main Wayland window? Like, a GTK title bar, a close button or something? Perhaps you have a messed up libdecor configuration just like a user had in #89793.

BTW I just forget to mention that when I'm trying to resize the window, in the log file (the first wayland log) has this "event" Pointing window. I don't know is it related or not, but this is what happening in that moment.

That's just a debug statement. Currently the verbose Wayland log is very verbose as it's still experimental.

[gregcsokas]

beta-3 full screen (I'm using a Nordic (gtk?) theme if this is the interesting part) Here is a full screenshot (it's quite big)

[Riteo]

@gregcsokas welp there's a title bar so supposedly libdecor (a client-side decoration library) is doing its job. The resizing cursor appears, right?

[gregcsokas]

Okay, I found something, and at this point it's makes everything way more trickier. There is a way, to arrange windows in gnome, if I grab them and pull to the edge of the monitor, then the window will be resized exactly to the half of the screen Here is a video about this https://youtu.be/R2k9PG-TXFE?si=Lp25EwsDeiXKtA8T&t=57

So if I do this with the Godot editor (since I have a fresh build if beta-2, it's a beta version independent issue) I lost the ability to resize it. If I put a different window to the other side, I can resize them together (I can set them up to cover different amount from the screen. So if I put the window this position I cannot resize it.

And if I don't do this just, I can resize the editor, but it's like 2FPS and

https://github.com/user-attachments/assets/7f1d010b-69df-4cfa-b40f-96a1a5342957

[Riteo]

@gregcsokas ohhh I see. So, if I understand correctly, you can't resize the window only if it's tiled like that? I can replicate that.

I have a sneaky suspicion that this might be another libdecor bug, as we're not controlling directly any of this stuff, we'll see.

Regarding the 2fps resize, I suppose you've built the editor with the default flags, which spits out an unoptimized binary. The online release version of beta2 should run much, much quicker.

Update: looks indeed like a libdecor bug :[

I can replicate this issue with the fancy GTK header (the gnome-y one you're using) but not with the fallback cairo one (which is very plain)

[gregcsokas]

Yes, when it's snapped or tiled I can't resize, for some reason, and since I have a big ass screen I'm regularly using this feature that I was unaware of the fact I'm probably using in a niche way :D so naturally just snapped on the side of the screen and "Ohh wait there is something wrong"

I have a sneaky suspicion that this might be another libdecor bug

So then it's not Godot-related. I assume then we are done here.

the only command that I'm using is this scons -j 16 platform=linuxbsd precision=double bits=64 module_mono_enabled=yes tools=yes target=editor

or are you talking to compile with system libraries?

[Riteo]

So then it's not Godot-related. I assume then we are done here.

Let's keep it open though. I'll report a bug upstream soon™.

or are you talking to compile with system libraries?

If you're talking about optimization, it's a special compiler mode that takes more time to build but gives a faster final executable. Contrary to what I said, the flags you passed will actually enable some optimizations. My bad.

Compiling with system libraries makes building faster as in, taking less time to make, but I doubt that it would help with final performance a lot.

I don't feel like giving advanced tips, but I'm quite sure that you're missing production=yes^1, which turns on a very advanced and costly optimization technique called LTO (Link-time optimization), along other useful things enabled in the official releases. When I say costly, I mean that the compiler will take a lot more time and use a lot more ram (7 GBs).

LTO should help considerably with performance once it's done making your laptop a very expensive space heater xD

If the bad resizing persists, let me know, as it's not supposed to be that slow.

PS: looks like the tools flag isn't needed anymore :D

[Calinou]

LTO should help considerably with performance once it's done making your laptop a very expensive space heater xD

lto=thin allows you to get most of the performance benefits of LTO, but with much faster linking times and lower RAM usage. It's not supported on all platforms and compilers though.

[gregcsokas]

I built a new version of beta-3, with the command below. scons platform=linuxbsd bits=64 module_mono_enabled=yes precision=double target=editor production=yes use_llvm=yes lto=thin

Resizing is still slow, Then I removed the custom theming from the os and nothing changed. Then I reset the editor theming to the default and no improvement.

Here is a fresh log wayland-debug.log

[Riteo]

@gregcsokas how slow? Still like, 2FPS? Is XWayland faster?

[gregcsokas]

2fps slow, the video is about xwayland

https://github.com/user-attachments/assets/28269054-29f8-46f7-a716-ceda5e3e40e5

[Riteo]

@gregcsokas, thanks for finding this out. I had some trouble reproducing this on sway but then I pulled the newest commits and it's molasses-slow here too. I think it might be related to #93684 but I'm not sure. I'll take a closer look.

Could you please open a new ticket, so that we can track it there?

[gregcsokas]

Yes I will create a new one :)

[Riteo]

@gregcsokas hold on! After a whole day of messing around (because I couldn't reproduce it reliably) I'm quite sure that what you're seeing is not a bug: look at the editor's "output" tab in the wayland video! It's got almost 3000 entries, that's what slowing the renderer down!

Sorry, before opening the ticket, please try running the latest master (which does not have the error spam bug) without the --verbose flag. It should make for a fairer comparison to the XWayland video.

Edit: to be clear, once I spammed my console with a few thousand entries it finally lagged like in your video. That's why I'm so sure.

[gregcsokas]

I built a version from the rc-1 and the resizing is still 2fps

Here is the log (if it shows anything without the --verbose) I've used this command. WAYLAND_DEBUG=1 ./bin/godot.linuxbsd.editor.double.x86_64.llvm.mono > wayland-debug.log 2>&1 wayland-debug.log

[Riteo]

@gregcsokas mhhh... Nothing looks terribly out of place from a quick glance. Feel free to open a ticket then, I might also have a patch that you could try :D

See ya there, I'll soon take a closer look in the meantime.