Window width/height override degrades performance when base viewport w/h is low resolution

[Axis4s]

Tested versions

Godot 4.4

System information

Godot v4.4.1.stable - Windows 10 (build 19045) - Multi-window, 1 monitor - OpenGL 3 (Compatibility) - AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21923.1000) - AMD Ryzen 5 5500U with Radeon Graphics (12 threads)

Issue description

Using the window width/height override options in the project settings to scale up the small viewport results in huge loss of framerate.

Original Viewport Res: 320x240
Override: 1280x960

Steps to reproduce

Create a Scene with your viewport set to a low resolution, 320x240 and your window override to 1280x960 and include a canvas-layer with a label on it with a simple "get_frames_per_second" script

Minimal reproduction project (MRP)

exp-01.zip

[Calinou]

I can't reproduce this on 4.5.beta1 on my end (I get 5600 FPS in both cases), but I have a much faster CPU/GPU:

PC specifications

• CPU: AMD Ryzen 9 9950X3D
• GPU: NVIDIA GeForce RTX 5090
• RAM: 64 GB (2×32 GB DDR5-6000 CL30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 42)

However, if I force software rendering through Xephyr + llvmpipe, I will get much lower FPS in both cases. In this situation, scaling has a significant cost (Xephyr is at 1280×960 in both cases, but it displays lower-resolution apps centered):

• 320x240: 620 FPS (1.61 mspf)
• 1280x960: 385 FPS (2.60 mspf)

This is a frametime difference of around 1 millisecond per frame. Given this is software rendering we're talking about (which scales very poorly with resolution), I consider this to be within acceptable limits.

When doing performance comparisons, remember to compare frametimes (milliseconds per frame/mspf) instead of frames per second, as FPS is a non-linear measurement.

Here, the difference in frametime between the two tests is 2.83 mspf (1000/354.0 - 1000/1843.0). This looks significant, but for not-so-recent integrated graphics (especially on battery or a low power profile), it's not out of the ordinary. Remember the blitting the viewport to a higher resolution window does have a performance cost in any engine (even software rendering is impacted by this).

[Axis4s]

I can't reproduce this on 4.5.beta1 on my end (I get 5600 FPS in both cases), but I have a much faster CPU/GPU:

PC specifications

• CPU: AMD Ryzen 9 9950X3D
• GPU: NVIDIA GeForce RTX 5090
• RAM: 64 GB (2×32 GB DDR5-6000 CL30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 42)

However, if I force software rendering through Xephyr + llvmpipe, I will get much lower FPS in both cases. In this situation, scaling has a significant cost (Xephyr is at 1280×960 in both cases, but it displays lower-resolution apps centered):

• 320x240: 620 FPS (1.61 mspf)
• 1280x960: 385 FPS (2.60 mspf)

This is a frametime difference of around 1 millisecond per frame. Given this is software rendering we're talking about (which scales very poorly with resolution), I consider this to be within acceptable limits.

When doing performance comparisons, remember to compare frametimes (milliseconds per frame/mspf) instead of frames per second, as FPS is a non-linear measurement.

Here, the difference in frametime between the two tests is 2.83 mspf (1000/354.0 - 1000/1843.0). This looks significant, but for not-so-recent integrated graphics (especially on battery or a low power profile), it's not out of the ordinary. Remember the blitting the viewport to a higher resolution window does have a performance cost in any engine (even software rendering is impacted by this).

so wait, this means my laptop is using software rendering instead of its igpu? also i do use ultimate performance power plan which is an hidden option that you need to use a command to enable on windows, so my laptop's battery shouldn't be limiting performance, also did another test where enabling the "Keep the aspect ratio of the embedded game." also makes the framerate suffer

also i noticed the frametime improves for some reason whenever i move the window? tbh its bit hard to tell, since its all over the place, 0.5ms to 5ms

[Axis4s]

Switched over EndeavourOS Arch-Linux

Godot v4.4.1.stable.arch_linux - EndeavourOS #1 SMP PREEMPT_DYNAMIC Sun, 06 Jul 2025 11:14:36 +0000 on Wayland - X11 display driver, Multi-window, 1 monitor - OpenGL 3 (Compatibility) - AMD Radeon Graphics (radeonsi, renoir, ACO, DRM 3.63, 6.15.5-arch1-1) - AMD Ryzen 5 5500U with Radeon Graphics (12 threads)

it seems blitting the viewport to a higher resolution on arch linux systems does not hinder the performance that much compared to windows 10

[Calinou]

so wait, this means my laptop is using software rendering instead of its igpu?

Probably not, but you can check by opening Godot from a terminal and looking at the OpenGL Renderer line on startup. If it says llvmpipe, then it's using software rendering. On Direct3D 12, the equivalent software renderer is WARP.