Move away from texture-size based sizes of components and icons in default controls

[lostminds]

I've been working a lot with getting UI things to work and render as expected on hiDPI monitors (see #7968 for more general explanation) and when working standard UI controls I've repeatedly run into an issue with built in texture-based components (like icons, grabber handles etc) in controls being sized based on their texture size.

This works fine when you render the control at 100% scale/resolution, and when you do it will automatically make the components larger/smaller if you customize the theme to use a larger or smaller texture. However, if you render the UI in hiDPI (or do any other type of interface scaling) this leads to problems, since you can't configure the theme to use higher resolution textures without this also changing the size of the controls:

So as you can see rendering of text, styleboxes etc is rendered at the correct higher resolution, but texture components of controls are rendered at low resolution and instead just made larger. As far as I can tell the only way to get around this and get the control to render higher resolution components is to make your own subclass and render the higher resolution textures on top of the base control or replace it entirely. This applies to for example Checkbox, Slider, TabBar, Tree, and probably more.

The solution in my mind would be to never use the texture size to set the size of any of these icons, and instead let this be set up size properties (like a grabber_size for Slider or using the Checkbox control size to scale the icon). However, since we now have this implementation and don't want to break compatibility we need to implement this in some way that falls back to the current way of working for existing themes.

I can imagine specific fixes for different Controls (like again, a new grabber_size parameter for Slider, or a size_icon_to_height option on Checkbox) and could make proposals for such changes, but since this is a more general problem perhaps there's some better way of handling this in the same way in all controls for consistency? Or even implementing something more low-level like how macOS and iOS does it where UI/2D-Textures could have resolution scaling built into them so that the control can still think the icon image size is 16x16 while the texture backing on hiDPI systems actually has 32x32 pixels? What do you think?

[Calinou]

Doing so by default would break compatibility with existing projects, and applying this new approach in new projects could easily be confusing. It would lead to people wondering why their newly set up theme looks different from the same theme configured in an older project.

Instead, I think this is something that should be opt-in. There is a Texture2D property that allows overriding the physical size of any texture displayed in 2D, but it's currently not exposed to scripting. (This naturally has no effect in 3D scenes.)
I've brought up that property in another issue or proposal, but I can't find it right now.

Or even implementing something more low-level like how macOS and iOS does it where UI/2D-Textures could have resolution scaling built into them so that the control can still think the icon image size is 16x16 while the texture backing on hiDPI systems actually has 32x32 pixels? What do you think?

This is already possible if you design your UI for a high base resolution and let it downscale with the canvas_items stretch mode, or use a custom scale factor lower than 1.0 to perform downscaling (with any stretch mode).

There's a Default Theme Scale project setting you can change to adjust the scale at which the default project theme is generated.

[lostminds]

Yes, this needs to retain some function for backwards compatibility of course, like for example having the default grabber_size be 0, and have that mean the texture is sized based on its resolution like now.

The "physical size" property for texture2d sounds like another very promising solution. Perhaps this could then be controlled in the import settings for the image? That way you could have your 24x24 high res grabber knob image and specify in the import settings that it should be considered having a 12x12 size in the interface. Combined with the Generate mipmaps option this would then also mean that a pre-downscaled 12x12 version would be available for cases where the control is rendered at normal resolution so this could be the default setting for all built in control components.

[Calinou]

Perhaps this could then be controlled in the import settings for the image?

That was my original thought. The only question is whether it should be set as an absolute size in pixels or a scale, similar to the svg/scale import option. I'd go for a scale factor personally.

[lostminds]

I think either could work. A scale factor could work calling it something like resolution_scale and conforms to notions like having @2x version of graphics files on iOS/macOS. And it would have the benefit of allowing a default value of 1 just working like it does now without needing special "if 0"-case rules.

The drawback would I guess be that since it's the explicit absolute size that will be used by the engine to size things you need to think in several steps and first ensure the texture is the correct size and then set the correct factor for the size to get the result you want. But since the typical case will probably be using double resolutions graphics and a factor 2 for these that shouldn't be too much of an issue. If it's just a single factor it also won't be possible to have the resolution scaling be non-uniform, but I'm not sure if that would ever be desirable anyway. So maybe that just removes a possible mistake you could make setting an absolute physical size.

[bruvzg]

Auto scalable SVG textures are implemented as part of godotengine/godot#86022, for both the editor icons and UI elements (if theme resource are SVG based).

[lostminds]

Sounds great! Would this then be controlled by some new import resolution independent scaling setting on the svg image to use this new SVGTexture representation instead of the current loading of SVGs by rendering them at a fixed scale?

[hecto600]

Is there any updates about this functionality? I tried to use these available options for icons but never achieved a good result as like with fonts.

[Calinou]

godotengine/godot#86022 is still a work in progress. Since 4.3 is in feature freeze, any new features can only be merged in 4.4 at the earliest.

[artcodefun]

As far as I can tell the only way to get around this and get the control to render higher resolution components is to make your own subclass and render the higher resolution textures on top of the base control or replace it entirely. This applies to for example Checkbox, Slider, TabBar, Tree, and probably more.

It seems like you can also use MeshTexture for this instead of CompressedTexture2D 😬