godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.13k stars 21.19k forks source link

window ignores min_size set from DisplayServer if wrap_content is set and scaling not 1 #97764

Open leogott opened 1 month ago

leogott commented 1 month ago

Tested versions

Reproducible in 4.3-stable

System information

Godot v4.3.stable - Pop!_OS 22.04 LTS - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 580 Series (RADV POLARIS10) - AMD Ryzen 7 7700X 8-Core Processor (16 Threads)

Issue description

There are several inconsistencies and bugs with the way godot determines the minimum and current window size. Here, a scaling factor of 2 causes godot to discard the values set from DisplayServer.window_set_min_size, as soon as wrap_content is set to true.

This issue only exists when a scaling factor is set in the project settings (or gdscript i guess)

Steps to reproduce

  1. Move the Slider labeled DisplayServer.window_set_min_size all the way to the right.
  2. Toggle the wrap_controls button
  3. Observe as the window size snaps to the smaller size

(if testing in 4.3, ignore the presence of #91960)

Minimal reproduction project (MRP)

resize_mwe.zip

bruvzg commented 1 month ago

DisplayServer.window_set_min_size should not be used directly, it's a low level API (same is true for most other DisplayServer methods), use Windows min_size property instead. Window class will override a lot of properties with its cached values when updated. You can use get_window() to get current window from the code.

leogott commented 1 month ago

So this is working-as-intended / fix-in-documentation then? With the added knowledge that Window methods do not care for, and may write over values set via DisplayServer methods, this behavior is somewhat predictable. But from a skim-read of the documentation I would not have grasped that

bruvzg commented 1 month ago

So this is working-as-intended / fix-in-documentation then?

Yes, some of DisplayServer methods have Advanced users only! Adding such a callback to a [Window] node will override its default implementation, which can introduce bugs. note, but not all.

Native window controlled by DisplayServer is a temporary object and only exist when it's visible (and window embedding is enabled), so Window can't rely on DisplayServer for storing any properties.