Unexpected behaviour for viewport stretching aspect "expand" and scale_mode "integer"

[svn133]

Tested versions

• Reproducible in: 4.2.2.stable, 4.3-dev6

System information

Godot v4.2.2.stable - macOS 13.5.0 - GLES3 (Compatibility) - Intel(R) Iris(TM) Plus Graphics OpenGL Engine - Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz (8 Threads)

Issue description

I try to achieve the following configuration for my project:

• display in window
• use full window for content rendering (no black borders)
• content should scale up/down based on window size
• pixel art (perfect pixel rendering, i.e., content-scaling in steps)

I tried to achieve this with the following configuration

• setting the viewport size to something like 320x180
• window, resizable
• stretch mode: viewport (or canvas_items)
• aspect: expand (!)
• scale mode: integer (!)

The combination "expand" with "integer" should lead to the desired behaviour, but it is not actually doing so in most window-sizings.

When using scale mode "fractional" instead, I get the basic desired behaviour for content-filling/expansion, only the content-scaling is not "stepping" in that variant.

---

Observed behaviour (vs. expected)

1. onle resizing horizontally

   • no scaling change (ok)
   • viewport is expanded horizontally (ok)
   • no black borders (ok)

2. only resizing vertically

   • no content-scaling (ok)
   • viewport is expanded vertically (ok)
   • no black borders (ok)

3. resizing both directions simultanously

   • content scaling is happening in steps (ok)
   • viewport sizing is jumping strangely, only ever expanding one direction (unexpected)
   • black borders show up in most sizings (unexpected)

---

Remarks on behaviour

When comparing the observed behaviour with the behaviour of the same configuration but using "fractional" for scale mode, I hav the impression that this is bugged (or at least inconsistent).

When resizing in both directions at the same time, I expected this configuration to behave basically exactly like for scaling mode "fractional" (i.e., no black borders), with exception that the content scaling is happening in a stepped way.

I'm not sure if the current behaviour is actually desired as is, or if this really is a bug. At least for me, it feels like a bug (or at minimum very inconsistent in comparision with "fractional" behaviour).

I hope the attached visualizations clarify the expected vs. actual behaviour for this.

---

Here are some places I saw similar (or almost similar) behaviour as desired/expected for this combination:

1. https://github.com/godotengine/godot-proposals/issues/1666

   • this seems to be the original proposal where the current implementation originated
   • in that proposal, the behaviour for "simultanous resizing" matches my expectations

2. https://www.reddit.com/r/godot/comments/18ll9cp/integer_scale_mode_expand_without_black_bars/

   • somebody asking how to achieve a simular behaviour
   • not exactly the same, but near enough for me to gauge that I'm not the only one searching for that :-)

---

This seems to be the problematic code, I'm noticing an xor/branching for "expand vertically" vs "expand horizontally" which is likely the origin of the behaviour...?

https://github.com/godotengine/godot/blob/master/scene/main/window.cpp#L1056

---

A short video where I demonstrate the behaviour first with "integer" mode and then with "fractional" mode. Both "should" almost look the same, except for the stepped content-scaling, but they differ extemely.

https://github.com/godotengine/godot/assets/114500633/7081ab30-35c0-44e3-836a-16f45ca45398

Steps to reproduce

1. new project
2. window configuration as described
3. add a few anchored labels or some content to the scene
4. start and resize
5. switch between "integer" and "fractional" scaling modes and restart/retry

(or just use attached example project)

Minimal reproduction project (MRP)

unexpected-integer-scaling-project.zip

[svn133]

In case this is not clear from the description: this affects both Controls and other non-UI 2D nodes.. I just used Control elements in the demonstration to keep it simple.

[AThousandShips]

The GUI tag part is for the window behaviour itself, more than the elements scaling, as the behaviour is likely related to the way it handles the viewport itself