[2D]-Linux/KDE/X11/RTX 3060-No GDScript & One 640x360 Background Image-Very Slow Performance When Resizing Game's Window?

Help
, ,
1

Godot Version

v4.6.2.stable.official [71f334935] - “CachyOS” KDE Plasma Linux (Arch Linux based)

Question

Hi,

Our previous three Godot games were 100% GDScript source code and none utilized the IDE.
For our fourth Godot Engine 4.x.x game we will be utilizing the IDE and use less GDScript.

We have a 640x360 game window and one 32Bit 640x360 background sprite so far.
When we run the game on Linux and try to resize the game’s window it is very slow?
Slow like Microsoft Office PowerPoint slideshow slow?

Any ideas about the above?
We will list the specifications of the desktop below to help:

Let us know, thanks!

SS

________________________________________________
❯ inxi -Fxz
System:
Kernel: 7.0.0-1-cachyos arch: x86_64 bits: 64 compiler: clang v: 22.1.3
Desktop: KDE Plasma v: 6.6.4 Distro: CachyOS base: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: TUF GAMING X570-PLUS (WI-FI) v: Rev X.0x
serial: Firmware: UEFI vendor: American Megatrends
v: 5044 date: 01/04/2026
CPU:
Info: 8-core model: AMD Ryzen 7 5800X bits: 64 type: MT MCP arch: Zen 3+
rev: 2 cache: L1: 512 KiB L2: 4 MiB L3: 32 MiB
Speed (MHz): avg: 3592 min/max: 556/4854 boost: enabled cores: 1: 3592
2: 3592 3: 3592 4: 3592 5: 3592 6: 3592 7: 3592 8: 3592 9: 3592 10: 3592
11: 3592 12: 3592 13: 3592 14: 3592 15: 3592 16: 3592 bogomips: 121371
Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a
ssse3 svm
Graphics:
Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate]
vendor: Micro-Star MSI driver: nvidia v: 595.58.03 arch: Ampere
bus-ID: 0b:00.0
Display: x11 server: ``X.Org`` v: 21.1.22 with: Xwayland v: 24.1.10 driver: X:
loaded: nvidia unloaded: modesetting gpu: nv_platform,nvidia,nvidia-nvswitch
resolution: 1: 1920x1080~60Hz 2: N/A
API: EGL v: 1.5 drivers: nvidia,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland,device-1
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 595.58.03
glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 3060/PCIe/SSE2
API: Vulkan v: 1.4.341 drivers: nvidia surfaces: N/A devices: 1
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor gpu: nvidia-settings,nvidia-smi
wl: wayland-info x11: xdpyinfo, xprop, xrandr
Audio:
Device-1: NVIDIA GA106 High Definition Audio vendor: Micro-Star MSI
driver: snd_hda_intel v: kernel bus-ID: 0b:00.1
Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio
vendor: ASUSTeK driver: snd_hda_intel v: kernel bus-ID: 0d:00.4
API: ALSA v: k7.0.0-1-cachyos status: kernel-api
Server-1: sndiod v: N/A status: off
Server-2: JACK v: 0.126.0 status: off
Server-3: PipeWire v: 1.6.3 status: active
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
driver: r8169 v: kernel port: e000 bus-ID: 05:00.0
IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac:
Device-2: Intel Wi-Fi 5 Wireless-AC 9x6x [Thunder Peak] driver: iwlwifi
v: kernel bus-ID: 06:00.0
IF: wlan0 state: down mac:
Device-3: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: ASUSTeK driver: r8169 v: kernel port: d000 bus-ID: 07:00.0
IF: enp7s0 state: down mac:
IF-ID-1: wg0-mullvad state: unknown speed: N/A duplex: N/A mac: N/A
Bluetooth:
Device-1: Intel Wireless-AC 9260 Bluetooth Adapter driver: btusb v: 0.8
type: USB bus-ID: 3-5:4
Report: btmgmt ID: hci0 rfk-id: 0 state: up address: bt-v: 5.1
lmp-v: 10
Drives:
Local Storage: total: 18.24 TiB used: 460.9 GiB (2.5%)
ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKNU020TZ size: 1.86 TiB
temp: 34.9 C
ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 980 PRO 2TB size: 1.82 TiB
temp: 47.9 C
ID-3: /dev/sda vendor: Seagate model: ST12000VN0008-2YS101 size: 10.91 TiB
ID-4: /dev/sdb vendor: Western Digital model: WD40EFAX-68JH4N1
size: 3.64 TiB
Partition:
ID-1: / size: 1.82 TiB used: 460.06 GiB (24.7%) fs: btrfs dev: /dev/dm-0
mapped: luks-123da7e7-b7ca-4808-88ea-dd6aad903482
ID-2: /boot size: 2 GiB used: 859.5 MiB (42.0%) fs: vfat
dev: /dev/nvme1n1p1
ID-3: /home size: 1.82 TiB used: 460.06 GiB (24.7%) fs: btrfs
dev: /dev/dm-0 mapped: luks-123da7e7-b7ca-4808-88ea-dd6aad903482
ID-4: /var/log size: 1.82 TiB used: 460.06 GiB (24.7%) fs: btrfs
dev: /dev/dm-0 mapped: luks-123da7e7-b7ca-4808-88ea-dd6aad903482
ID-5: /var/tmp size: 1.82 TiB used: 460.06 GiB (24.7%) fs: btrfs
dev: /dev/dm-0 mapped: luks-123da7e7-b7ca-4808-88ea-dd6aad903482
Swap:
ID-1: swap-1 type: zram size: 62.7 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
System Temperatures: cpu: 50.1 C mobo: N/A gpu: nvidia temp: 62 C
Fan Speeds (rpm): N/A gpu: nvidia fan: 0%
Info:
Memory: total: 64 GiB note: est. available: 62.7 GiB used: 12.53 GiB (20.0%)
Processes: 559 Uptime: 6h 41m Init: systemd
Packages: 1493 Compilers: clang: 22.1.3 gcc: 15.2.1 Shell: fish v: 4.6.0
inxi: 3.3.40

2

Like actively resizing the window up and down is slow or after resizing once it’s slow? The former is a very taxing operation, resizing a window will be very slow, it is not expected to happen often.

3

Hi,

Something is wrong here…

I think today my Linux OS updated to Kernel 7.x.x.
I’ll fallback to the 6.x.x Kernel to test.

The above is not normal.

SS

NOTE #1: Not an issue with the 7.x.x Kernel, just checked

NOTE #2: Getting below errors in Godot 4.6.2 IDE:
— Debugging process stopped —
ERROR: platform/linuxbsd/x11/display_server_x11.cpp:1310 - Unhandled XServer error: BadWindow (invalid Window parameter)
ERROR: Major opcode of failed request: 25
ERROR: Serial number of failed request: 0
ERROR: Current serial number in output stream: 8333

4

Did you open Steam (Or any other program, we don’t quite know what causes it for a fact) while this was happening? Looks related to this.

5

Yes, something wrong with X11, Godot v4.6.2, & Steam on Linux.
I am using Wayland now and no errors occur.

More interested in why the resizing is so slow though?
None of my other applications on CachyOS Linux show the same resizing performance issues….

6

Godot is probably reconstructing the graphics pipelines and frame buffers to adapt to the new resize for each resize event. Other applications may not have complex rendering pipelines and do not require reconstruction, or they may wait to handle resizing once the dragging ends.