Restructure Viewport size and size_2d_override

[Sauermann]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

godotengine/godot#72548
I believe that the necessary changes to fix this bugreport will need to include a rewrite of Viewport.size and Viewport.size_2d_override. Since this is a bit larger change, I want to accompany it with this proposal and also to discuss if this change makes sense.

Currently the semantics of Viewport.size and Viewport.size_2d_override are not very clear (description taken from SubViewport-doc):

• size: The width and height of the sub-viewport. Must be set to a value greater than or equal to 2 pixels on both dimensions. Otherwise, nothing will be displayed.
• size_2d_override: The 2D size override of the sub-viewport. If either the width or height is [code]0[/code], the override is disabled.

From how I understand the implementation in Window, the two have the following meaning:

• size: size of the viewport texture
• size_2d_overrride: area-size of the viewport-texture, that should be used for display. The rest of the viewport-texture is not displayed.

The following questions are unanswered:

• What does override mean?
• Which coordinate-system does each of the values represent?
• In the case that size<size_2d_override, why is no viewport-content displayed outside of the-size-area?

In some cases, size_2d_override is used as the size of the viewport, even if it isn't the size of the viewport, which lead to the problems mentioned in the above linked issue.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I want to suggest to replace the two options size and size_2d_override by the following:

• size_of_texture: size of the viewport texture in pixel
• size_of_display_area: size of the area, that the viewport texture is displayed in (the viewport announces this as its size)

This should make the meaning of each option more clear and get rid of the ambiguous override-wording.

Viewport.stretch_transform would stay more or less the same as size_of_texture / size_of_display_area. This is necessary for Transform-calculations.

SubViewport.stretch would need to be changed to adjust both values and fix the above linked bug.

Window._update_viewport_size would need to be adjusted.
I am not entirely sure and this would need to be tested, but the change might help with godotengine/godot#36507 by reducing the actual viewport texture size.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I will try to implement the changes and update this section later.
Since this will touch areas like Window::_update_viewport_size, and also possibly (will need to investigate) RenderingServer, this might take some time.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Since these are internals, no.

Is there a reason why this should be core and not an add-on in the asset library?

This is core-behavior.

[hayahane]

I'm running into a similar problem with SubViewport. I'm trying to make a pr for scaling the resolution of editor 3d viewport instead of having only half-res toggle, temporarily prototyping with gdscript.

Since I regard viewport as a render target, I suppose the SubViewport node should only have parameters that rendering needs which is the resolution. Other things like stretching should be handled where the SubViewport is consumed, for example in my case SubViewportContainer.

I'm willing to help but it may take some time for me to study related code.

[Calinou]

I'm trying to make a pr for scaling the resolution of editor 3d viewport instead of having only half-res toggle, temporarily prototyping with gdscript.

I would recommend just using the Viewport.scaling_3d_scale property now, since it handles everything for you and supports multiple scaling filters. It also doesn't suffer from input handling idiosyncracies. Since 4.3, this property works in the Compatibility rendering method as well.

Right now, the 3D scaling project settings are used in the editor, but we should make it so these are ignored in the editor and editor-specific overrides are used instead.