Uneven control node scaling with canvas_items stretch mode

[georgwacker]

Tested versions

Godot v4.3.dev [4e990cd7e] I noticed this in 4.1.2 as well

System information

Godot v4.3.dev (4e990cd7e) - macOS 14.3.0 - Vulkan (Forward+) - dedicated AMD Radeon RX 6800

Issue description

I've ran into an issue with control node scaling when using canvas_items stretch mode with expand and fractional.

This is a cropped image of the rendered window with 430x932px, where the boxes are all 88x88px. The first two boxes have a border width of 4px left, 4px top, 5px right, 5px bottom. With the last two boxes they are 4px on the left and 5px top, right, bottom. With the allotted space of 88x88px they should all be 5px.

In the base viewport resolution of 180x320px the boxes are all 37x37px with a border of 2px. This is a faux pixel art style with control nodes (the project started out as pure pixel art with viewport scaling).

I've tested this with different methods, the boxes are:

• Panel with border
• Border segments made with individual ColorRects
• Nested Sprite2D inside control node
• TextureRect set to keep size / scale

The expected behavior for canvas_items stretch mode would be an even scale of these control nodes. Or am I missing something?

At first I thought this might be related to container sizing, because I have these boxes setup in a tree of MarginContainer - VBox - Hbox. But the same thing happens with freely positioned control nodes. The ones in the screenshot all have integer number transform positions.

This happens with all three rendering methods, the snap settings did not change the outcome.

Where would be a good place to start investigating, scene/gui/control.cpp?

Steps to reproduce

See issue description

Minimal reproduction project (MRP)

ScaleTest.zip

[AThousandShips]

Please provide an MRP to make this easier to investigate:

• A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).
• Having an MRP is very important for contributors to be able to reproduce the bug in the same way that you are experiencing it. When testing a potential fix for the issue, contributors will use the MRP to validate that the fix is working as intended.
• Drag and drop a ZIP archive to upload it (max 10 MB). Do not select another field until the project is done uploading.
• Note for C# users: If your issue is not C#-specific, please upload a minimal reproduction project written in GDScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a .NET setup available.

[georgwacker]

Added MRP