So, it seems like GNOME’s version of “fractional scaling” is essentially just a more granular form of integer scaling. What I mean is that it would seem that we are locked to fractions which divide evenly. This really limits the degree to which we can scale our windows.
For me, 100% scaling feels a little too small, but I like how much space it grants me, and 133% is too crammed, but I like that text is easier to read. I’d really like something in-between like 115%.
In the future, I hope we can get a slider with notches that the handle can snap to which represent integer and cleanly divisible fractions as it currently is, but where the user can select any value in-between. For example, I have good eyesight, so I might want 115% scaling for my 1440p monitor to keep things small and legible.
The current system doesn’t really address individual needs well. Users sort of need to compromise based on the limited offerings available. I understand there is probably a technical reason for this limitation, but in the future, I hope GNOME is able to overcome such limitations so that users can really scale to any arbitrary factor that best fits their needs, with clean rasterization.
Also, I think it would be nice to get sub 100% scaling, ie. 75%. I understand this might be challenging for font rendering, but I know it’s technically possible. Reason being, I used to have a 7" HP Stream 7 tablet powered by Windows 8.1. This tablet had a 720p screen and to keep it from being too crammed, they set the display scaling to ~75% which actually worked perfectly fine and kept things legible and comfortable to use. Having plenty of experience using very cheap displays on Linux that use asinine resolutions like 1366x768 (looking at you Hewlett Packard and Lenovo), I am all to familiar with the issues of trying to run software that was designed exclusively for 1080p monitors on a display that is slightly less that that. In such cases, especially for these all-too-common “budget resolutions”, a sub-100% option would really come in clutch to overcome the awkwardly oversized UI issue on said displays.
I hope this has some level of priority, even long-term, because it would make a wide range of hardware configurations more accessible to GNOME users, where they would otherwise be forced to use another desktop due to GNOME’s fractional scaling deficiencies. Be that sub-1080p monitors, or awkward resolutions that lack a comfortable scaling, like my Framework Laptop 13 with a 2256x1504 (3:2) monitor.
I just wanted to be heard. Thanks for giving us GNOME Desktop! <3
The trade off between this and allowing you to set any random value is that anything that does not result in a pixel-aligned value is going to make your whole desktop blurry and useless, which is not desirable. On top of that, there’s the fact that the windowing system protocol uses fixed point representation of floating point numbers, so there’s an inherent precision loss that does not allow any random scaling value.
Instead of using window scaling, change the font scaling in the accessibility panel.
Just because something it’s technically possible does not mean it’s desirable, or usable.
I feel like there must be a solution to this. It doesn’t make sense that it would need to be this way. Like, we are essentially generating the whole UI with vector graphics. IMO, the system should be designed in such a way that no matter what scale factor is used, you always get a perfect 1px, 2px, etc. line by truncating/rounding. You always get a pixel-perfect render of every element because the UI is just taking a vector and scaling it arbitrarily more or less with some clever logic for calculating consistent line work. I feel like leaning on cleanly divisible resolutions is a hack.
Why is it that this limitation exists in the first place? Other UI toolkits are able to handle this smoothly, like Swift on Apple, Android’s UI toolkit, hell, even web browsers have this problem solved as they also need to be able to render arbitrary raster and vector content at any arbitrary DPI. There must be a way!
I don’t know how you came to this opinion, but it’s tragically wrong on multiple axes.
Toolkits don’t use vector graphics at all: they all fill out textures and submit them as pixel buffers. Compositors take those buffers and composite them. None of the results are vectors, because GPUs don’t render vectors. We’re not targeting a Vectrex from 1982.
Toolkits need to align to pixel boundaries, and then the compositor needs to align the buffers to pixel boundaries. The pixel boundaries are a product of a scaling factor and of the screen resolution/pixel density. Even if support for proper fractional scaling protocol was available in toolkits and applications, you’re forgetting the long tail of toolkits and applications that have no idea what scaling is, let alone fractional scaling.
This is not how anything works, and your opinion is clearly not matching with reality.
Apple and Google do not have to contend with random hardware and form factors.
They don’t. It’s actually pretty easy to make a mess and get a blurry website; in most cases, web engines cheat, and approximate to the nearest pixel, thus breaking the illusion. In any case, this is still a single application, not a whole desktop.
In general, though, it seems you have a very limited understanding of the problem space, and you’re conflating the contents of the applications—which require alignment to the pixel grid even when rendering at a fractional scaling factor—with the composited output of the whole desktop—which requires pixel alignment of the position of every buffer at moment of composition output and pixel alignment of the size of the buffer requested by the toolkit in order to render the application contents. The problems occur when the accounting for both positioning and sizing, as well as the pixel alignment, happen at both ends of the pipeline, and that causes rounding errors to accumulate.
Yes, I am out of my league here. I’m not a system’s programmer, I’m an artist and Linux user. That’s why I’m asking you to please figure out a way to build it eventually. It can’t be impossible.
There’s no way you’re being serious here.
I wouldn’t mind too much if only GNOME applications supported true fractional scaling completely, with other tool kits falling back to divisible increments where need be. I have no idea how GTK is architected, but conceptually, I feel like for something like this to work, you would have window geometry defined by pixel count (x, y) and density. The geometry (like buttons, rounded symbolic icons) are vector graphics, meaning they are not defined at their source as raw pixels on a grid, but rather as mathematical equations which are placed on a pixel grid and rasterized into a buffer.
I feel like for there to be blurring at odd values, this rasterization stage, which would handle things like font rendering (fonts are often vector graphics btw), rasterizing and anti-aliasing outlines, rounded corners, symbolic scalable vector graphic icons, and other UI elements, would need to be doing something sub-optimally.
Because all the elements of a modern GNOME application window are defined by code (not baked into 2D pixel grids a la 2000’s UI toolkits), you have complete control over how the system rasterizes graphics. Therefore, you can cheat a little bit. You can compute, based on DPI, the thickness of lines for example, and snap lines to clean pixel boundaries using an algorithm. This way, when you rasterize it, it’s clean and clear, and looks proportional. You can clamp it at 1px, and let the intended visual weight be defined by the artist/programmer, and interpolate based on whole pixel values. Fonts can already be rendered at any arbitrary size, so that is already solved.
Also, since when has GNOME ever cared about anything other than advancing its own interests? This would be a weird time to back away from that. GNOME isn’t the type of desktop to hold on to some legacy cruft to make old applications work better at the expense of its own progress. GNOME has historically adopted cutting-edge technology and made controversial design decisions for its own benefit, even when it alienates common use cases. For example:
Not offering a server-side rendering solution for legacy applications, even as an opt-in.
Removing X11 support entirely.
Requiring systemd to function properly.
Hiding the “Log out” button for single-session users.
With exception of the last one, these are all examples of very reasonable moves away from conventions to unshackle GNOME from legacy architectures and development overhead, at the cost of breaking compatibility with legacy Linux software more broadly. So, I don’t think it’d be much of a stretch to say that if it would make GNOME a better, more modern platform which can scale better on more devices, that you would pick this time of any to put your foot down and say it goes too far.
I’m hoping somebody can find a cheat that works for GTK so that we can get that same level of clean rendering and flexibility. Websites are built using a combination of rasterized graphics (like jpg, png) and vectorized content (like divs, SVGs, fonts, CSS effects). This is a great example of a very complex problem space where you have to cleanly scale elements of arbitrary sizes which have mathematically-defined boundaries, which gives you the flexibility of choosing how to solve the problem of rasterizing this infinitely-scalable graphic to look good on an arbitrary pixel canvas. I’m using Brave browser right now (based on chromium), and I can scale super smoothly using pinch to zoom. Once I release the zoom gesture, the entire page sharpens and looks pristine. Same goes for Safari on my iPhone. I don’t think I could think of a better example than a web browser because it isn’t just “a single application”, a web browser must be able to render an infinite combination of toolkits and applications while looking good and running fast. I think a web engine would actually have a harder time getting this right because at least LibAdwaita is somewhat standardized and GNOME controls the infrastructure. Web browsers need to handle an infinite combination of rendering techniques, on every desktop and across multiple operating systems.
I don’t really like your energy. It’s giving, “I’m going to perform intellectual superiority for everyone here in order to to discredit your ideas and make them sound stupid so I don’t have to do work and solve this problem because it sounds hard.”
Any seasoned developer could tell that I’m not a systems programmer. You aren’t impressing anyone coming in here and being condescending to me. And you aren’t hurting my feelings. If I had any idea how to implement this myself, I would have already, or at the very leas I would have provided a technical analysis of the problem. Not my wheelhouse. I know it can be frustrating when somebody asks for something that would be hard to do, but I’m not demanding it, nor was I being disrespectful (until you gave me a reason to be). We both know it’s technically possible. I’m not trying to argue with you about whether or not I know what I’m talking about. I’m clearly not the guy who’s gonna build it. I’m the user making a case for a shortcoming I see in your software (hence feature request, not design proposal), and using my basic understanding of the technology to propose a potential solution that I would like to see.
And since you seem to conflate “vectors” with 1980’s technology exclusively, something tells me you won’t be the guy to build it either, so don’t act so smug. I know you’re a big shot developer, and you could no doubt contribute more in a day than I could in 1,000 lifetimes, but you don’t need to be so disrespectful. I didn’t come here to be disrespectful, I came here to hopefully inspire someone greater than me to improve the desktop platform I love. I absolutely love GNOME and appreciate the hard work and visionary talent that drives it. I understand that GNOME is the product of countless optimizations, untold hours of thankless work, and the culmination of many hard decisions that have been made over the years, and I couldn’t begin to comprehend the work it must take to maintain. But I’m not stupid, and I know what I want. I may not know how to build it, but that isn’t my job.
I hope that some day, GNOME will scale better on more devices because the current solution leaves a lot to be desired, and it’s going to cause a lot of pain when when trying to make it actually accessible on mobile. This is not something I need, and it is not something I demand. It’s something I’d hope to see planned for some future release that has yet to be determined, because it is a genuine accessibility issue. I think it would be a lovely and worthwhile upgrade, and a boon to all GNOME users, and I hope to see it happen one day!
If you’re trying to insult us here, then congratulations, you succeeded. This is a dick comment to make, which also is far from truth, seriously. You are not even remotely close to achieving what you want to achieve.
This forum isn’t a place for entitled users to come in here with their wishlists and reprimand contributors who spent countless hours on the problem space.
Have you considered the fact that you’re not in a position to order volunteers around? You said yourself you don’t know how things work here, so how come you arrived at the conclusion that whatever you’re doing here is productive?
This isn’t the first time you did this stuff. I am giving you a warning, one more time I see you doing this shit and you’re getting banned.
