Replies: 2 comments
-
Both fractional, and per-display scaling are very difficult to do with the current display server X11. There is support in the upstream libraries we use (namely LibMutter) for both of these types of scaling in Wayland. It is unlikely that we'll be able to offer improved support for either fractional scaling or per-display scaling until we make the transition to Wayland. Once that transition is completed, it will be much simpler to do. You can track our progress on Wayland in this GitHub project However, it is always going to be a better experience to avoid scaling whenever possible. Fractions of pixels do not exist. That is a physical limitation that cannot be denied. Fractional scaling is a workaround that results in blurry anti-aliasing. It will always be a better experience to use integer scaling. As you alluded to, as of elementary OS 6 the system stylesheet will set some values based on text size, such as padding in buttons and toolbars. However, this scaling does not apply to icons. Icons are hinted to discrete sizes (16px, 24px, 32px, 48px, 64px) and currently the toolkit (GTK) is not able to choose the nearest size icon dynamically. Developers must select the correctly hinted icon size manually. As far as I'm aware, there is not currently an effort to change this |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for the detailed answer!
As far as I know, this only applies for anything which does not natively support scaling, which also means, the fractional scaling we know today will be always a crook, while it would be always better to solve the problem at the root. For the icons, for instance, it would mean to only use vector graphics (such as SVGs). I think raster graphics from the underlaying toolkits/frameworks are used for historic reasons; this is, from todays view, of course a very bad design. Usually today one would never use raster graphics for computergenerated content, this especially applies for the web - but Desktop systems seem to be a different world. Applications have been developed (and seem to sometimes still are) in a wrong way when it comes to compatibility with different resolutions. On the other side much effort is put into fixing issues such like ugly fonts (antialiasing, hinting, subpixel rendering) due to the low resolution problem, because 1920x1080 (so-called "Full HD") renders to way too less pixels to even display fonts in a sharp way. Higher resolutions such like WQHD (2560x1440) or 4K (3840x2160) on the other side are still not standard. Another problem is, that only a 5K resolution would bypass the need of fractional scaling while extending the workspace, because 4K with pixel-doubling (the best way when it only comes to the quality) would be very sharp, but too small for many people. I hope, I understood all correct from that perspective. It looks like an almost unresolvable problem because of historic reasons |
Beta Was this translation helpful? Give feedback.
-
When chaning the text size, e.g. from Small to Large, not only the text (font) size is changed, but the size of UI elements too. This makes sense. It seems that behind the scenes this setting changes the value of org.gnome.desktop.interface is changed.
However, it seems that this setting does not change the size of UI elements such as the X icon (close) of the window controls. Also not the size of the card in the lock screen, sizes of the icons in plank or wingpanel are changed.
My question is: Do you plan to support a better UI scaling in future? For instance, users for WQHD screens (2560x1440) usually want an optimal scale of 125%. Due to the extreme bad support I have seens from all distros I tried, it seems that getting a good scaling mechanism in the Linux world is not a trivial task, while it is dead easy in the vector based web development. I read your article about fractional scaling, but as far as I know this only applies for applications which do not natively support scaling (= the OS tries to scale applications afterwards - which of course cannot really work good -, instead of telling the application to natively scale to a factor X). So, I want to stress, that my question only targets native scaling support for elementaryOS itself, such like the size of the icons in plank and wingpanel, the size of the cards in the login screen, but not for third party applications.
Additionally - I almost forgot it - a big issue is per-monitor scaling for multi monitor setups with different native resolutions. If you want 125% for a 1440p monitor, you want to keep your 100% for your 1080p monitor. Unfortunately the current scaling method does not allow that.
Beta Was this translation helpful? Give feedback.
All reactions