You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For those who are not aware about how godot creates the theme at the moment: (don't have to read, just backgroundinfo) On every startup
color settings and scale (dpi) settings are set for the current screen and user settings
all svg icons get loaded as strings, and nanoSvg is used to convert them to paths with color information
than for each nano svg struct the colors are replaced to the one set in settings (so the svg has to use one specific color otherwise it does not get colorised...)
nano svg struct gets rendered to a bitmap with the desired resolution and updated color (based on dpi setting)
ALL these steps are repeated when changing the theme in editor (thats why it usually almost a second)
I want to know if this is desired before I work on a pr (or someone else)
The Proposal
Modulation
The svgs need to be recreated to achieve different colours. the idea is to add a per texture modulation factor which gets used when the canvas item modulation is set to 1, 1, 1. This would allow to create all icons in pure white (maybe with some gradient on it, or a black border...) and just modulate them on the fly. the color could be configured with a json in the folder where the svg's are placed.
Effects like hovering over icons also would be highly improved because than the canvas item modulate color would be used, and multiplied with pure white (in the current light theme the colour is multiplied with the darkened version of the SVG and it is hard to see the difference)
caching icons
also it would make it easy to just buffer the icons in a texture atlas. because usually the sizes are not updated once the user has set them appropriately for his screen.
scale factor for Texture
this makes godot think the texture is higher or lower resolution. so a 32x32 bitmap with facor 0.5 would be drawn and treated like a 16x16. this is useful for nine patch themes that are used in hidpi.
scale factor for themes
This is where it gets really interesting:
Right not he hidpi theme some a somewhat weird concept because it literally is another completely new theme with different settings. Every property needs to be resettled, every stylebox recreated.
there always need to be two or more themes... or one autogenerated one (like how the editor does it)
If one Theme has a scale factor, and all get functions in themes and style box return the scaled value (with an option for the raw one get_content_margin_left(raw_value = false)) changing it would immediately update the whole theme and it would look good. For ninpatch style boxes the nine patch would just scale the used texture to the wanted size and scale the margins and by doing so it would kind of trick itself to be hidpi.
Why?
faster loading time
less work for godot users who want to provide different dpi versions. (current options are: programmatically create a theme and use a scale factor. which is a lot of code to write. And there is no documentation about it. or create multiple almost equivalent themes. Sounds super tedious to me. And than load the right one)
less confusion what hidpi means. What is use_hidpi, allow hidpi in the settings. there would be just one setting. use OS upscaling on hidpi screens (which is what the allow hidpi setting does). Than the user would set the themes scale based on the dpi from the screen. theme.scale_factor = os.get_dpi_scale() / 130 sidenote: the use hidpi setting loads the hidpi version of the default theme
better looking icon colors on hover.
allows for really easy setting for choosing custom icon colours
It also allows to rework the theme editor. It is really confusing at the moment. What theme is used in the viewport? which one in the theme editor? when is it using the hidpi one? ... (some settings require restart so it is even harder to figure out what is what.)
The theme editor should just use the setting from the theme to set the scale_factor.
There is one project wide theme for which you can set the scale factor + there is the option to choose one specific theme for a viewport by just assigning it to the topmost node (with the desired factor)
The text was updated successfully, but these errors were encountered:
The DPI part is a duplicate of godotengine/godot-proposals#6. As for the rest of the features proposed here, this should be requested in new proposals on the Godot proposals repository after searching for duplicates.
For those who are not aware about how godot creates the theme at the moment: (don't have to read, just backgroundinfo)
On every startup
ALL these steps are repeated when changing the theme in editor (thats why it usually almost a second)
I want to know if this is desired before I work on a pr (or someone else)
The Proposal
Modulation
The svgs need to be recreated to achieve different colours. the idea is to add a per texture modulation factor which gets used when the canvas item modulation is set to
1, 1, 1
. This would allow to create all icons in pure white (maybe with some gradient on it, or a black border...) and just modulate them on the fly. the color could be configured with a json in the folder where the svg's are placed.Effects like hovering over icons also would be highly improved because than the canvas item modulate color would be used, and multiplied with pure white (in the current light theme the colour is multiplied with the darkened version of the SVG and it is hard to see the difference)
caching icons
also it would make it easy to just buffer the icons in a texture atlas. because usually the sizes are not updated once the user has set them appropriately for his screen.
scale factor for Texture
this makes godot think the texture is higher or lower resolution. so a
32x32
bitmap with facor 0.5 would be drawn and treated like a16x16
. this is useful for nine patch themes that are used in hidpi.scale factor for themes
This is where it gets really interesting:
Right not he hidpi theme some a somewhat weird concept because it literally is another completely new theme with different settings. Every property needs to be resettled, every stylebox recreated.
there always need to be two or more themes... or one autogenerated one (like how the editor does it)
If one Theme has a scale factor, and all get functions in themes and style box return the scaled value (with an option for the raw one
get_content_margin_left(raw_value = false)
) changing it would immediately update the whole theme and it would look good. For ninpatch style boxes the nine patch would just scale the used texture to the wanted size and scale the margins and by doing so it would kind of trick itself to be hidpi.Why?
faster loading time
less work for godot users who want to provide different dpi versions. (current options are: programmatically create a theme and use a scale factor. which is a lot of code to write. And there is no documentation about it. or create multiple almost equivalent themes. Sounds super tedious to me. And than load the right one)
less confusion what hidpi means. What is
use_hidpi
,allow hidpi
in the settings. there would be just one setting.use OS upscaling on hidpi screens
(which is what theallow hidpi
setting does). Than the user would set the themes scale based on the dpi from the screen.theme.scale_factor = os.get_dpi_scale() / 130
sidenote: the
use hidpi
setting loads the hidpi version of the default themebetter looking icon colors on hover.
allows for really easy setting for choosing custom icon colours
It also allows to rework the theme editor. It is really confusing at the moment. What theme is used in the viewport? which one in the theme editor? when is it using the hidpi one? ... (some settings require restart so it is even harder to figure out what is what.)
The theme editor should just use the setting from the theme to set the scale_factor.
There is one project wide theme for which you can set the scale factor + there is the option to choose one specific theme for a viewport by just assigning it to the topmost node (with the desired factor)
The text was updated successfully, but these errors were encountered: