SubViewport not refreshing properly in-editor when reducing its size

[5ro4]

Tested versions

• Reproducible in 4.2.1-stable and 4.1.1-stable

System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.3623) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

Issue description

When reducing the size of a SubViewport in the editor, the viewport will show an incorrect stretched image (the SubViewport at the new size stretched to fit the previous size). Toggling the SubViewport Container visibility off and on fixes it.

viewport_bug.mp4

Steps to reproduce

Steps for the MRP:

1. Open sub_viewport_container.tscn
2. Select the SubViewport and change its size X from 500 to 400
3. Notice the stretched image
4. Toggle the SubViewport Container visibility off and on again
5. Notice the image is showing correctly now.

Minimal reproduction project (MRP)

_viewport_bug.zip

[jordi-star]

Fixed in #86302

[TheDuriel]

Hold on now.

This is desired behavior in my case. I want the subviewport to be stretched to the containers size if it is smaller. That's a feature.

[azagaya]

@TheDuriel this cannot be a feature if hiding and showing it causes to render differently. Also, just moving the container will cause to render correctly. There is no safe way to use this bug as a feature imho (unless im missing something).

[azagaya]

If you want this effect and in a consistent way, use Size 2D Override for the size of the viewport, and check Size 2D Override Stretch. Afaik, thats the way to achieve smaller viewport stretching the rendered image to the containers size.

[TheDuriel]

Which is why I am wondering if there hasn't been a different "issue" discovered. I'm doing some checks on 4.x and on 3.x for a moment to confirm what I expect to happen in this scenario.

I do acknowledge that hiding and revealing the viewport does force a redraw and thus a change in what is being displayed. But that isn't on its own able to tell us which scenario is wrong.

Could this actually be a symptom of the container not shrinking down when the viewport does? It's not certain what should happen in that case. We're in undefined behavior land now, and the proposed PR does not address that, since it forces a redraw but not a resort?

If you make a container at 100x100, and a viewport at 200x200, the container becomes 200x200. Then when you change the viewport to 100x100, the container remains at 200x200 so long as it does not get sorted by a parent container or shown/hidden. This is behavior which is being used by games.

Should the fix then not be, to queue a sorting of the container, which will in turn cause a redrawing? This then gives the correct result regardless of the uncertainty.

Additionally I wish to point out that the stretch shrink setting, does not allow the use of precise values. Which is necessary in some cases. - Though there may be some obscure combination of settings still achieving the desired effect. (I need to make an issue about how utterly obnoxiously obtuse window and resolution settings have become. You shouldn't need to rely on a combination of 4 or more properties to render and display at different resolutions.)

[azagaya]

It's not certain what should happen in that case. We're in undefined behavior land now

The docs states SubViewportContainer will use the combined size of the SubViewports as minimum size, not as its size, so i believe the behaviour is the intended. This way you can have it work correctly with Expand i believe. It would be also quite problematic if you resize the container manually, then resize the subviewport, and it would bring down the container size again. So again, i believe this is the intended behaviour (i may be wrong).

Additionally I wish to point out that the stretch shrink setting, does not allow the use of precise values

If i understood you correctly, you want the subviewport rendered image be always at a resolution, and stretched to cover the entire viewport container. If so, you dont need stretch shrink at all. You just need the settings i mentioned above.

[TheDuriel]

If i understood you correctly, you want the subviewport rendered image be always at a resolution, and stretched to cover the entire viewport container. If so, you dont need stretch shrink at all. You just need the settings i mentioned above.

I just tried and it was difficult to tell which combination of settings would actually achieve this. Especially with the inconsistency created by resizing the container/viewport. It's a mess.

---

So lets focus on the thing at hand: ViewportContainers will display different images depending on whether the viewport has been "redrawn". I will note that this isn't limited to static images. The viewport is still rendering frames fine.

I suggest that an attempt is made to queue a sorting of the container when the viewport changes size. Which in turn will cause the viewport to redraw. Achieving the same effect, but also respecting the fact that: Control nodes assume the size of their contents. Unless otherwise specified by the user.

Example: Changing the texture in a TextureRect node, will shrink the rect if the new texture is of a smaller size. SubViewportContainer does not behave the same, despite seemingly sharing the same stretch settings!

[jordi-star]

You can still achieve the stretching effect shown in the bug report video using the Size 2D Override property.

I believe size is intended to be the actual size of the Viewport, not the target size of the final image. Using the Size 2D Override will give you the same result predictably. Depending on the SubViewportContainer not redrawing is unreliable, as there are various actions that can trigger a redraw such as resizing the window, reparenting an ancestor, etc.