QT vs GTK, or the dead hand of Gnome

[Portreve]

I was just listening to Linux Unplugged: 482 and they were talking about how a lot of at least internal communication engagement for the Gnome Project is down significantly. I don't think this should necessarily be interpreted in a click-baity way to mean they're losing their community or their developers, but evidently there's a drop in excitement in at least some way.

I do still think it would be cool (and would support) Clem & Co. exploring rebasing Cinnamon on something else.

[billyswong]

The GTK team still refuse to support fractional scaling natively, neither what Microsoft did in Windows nor what Firefox / Chrome did for webpages zooming. Desktop environments are stuck implementing the oversizing-screen-buffer hack for them which incur unnecessary computational cost.

I once discussed this issue in another forum and a defender of GTK's decision claimed all the existing efficient fractional scaling implementations violate the modern no-flickering rule and are legal only because they were written before the law was passed. By this logic he/she claimed Wayland and GTK can't use those "shortcuts" because they get into the game too late.

I don't think oversizing the whole screen buffer or window buffer is the only conformant way to implement fractional scaling. But one can't wake up people who pretend to sleep.

It violates the law?! Wow, did not know that. What law is that? Fractional scaling is one of those things I was really waiting on in Linux. One more reason why GTK needs work.

https://en.wikipedia.org/wiki/Photosensitive_epilepsy
It is not clear if there are really law against once-in-a-blue-moon flicker in software. But law or not, I am okay for general OS features to be gated until flicker-free. I am not okay for using it as an excuse. Because from what I observe, the crowd in Wayland and GTK/Gnome development teams refuse implementing fractional scaling natively because they don't know how to make it pixel-perfect.

Yes, the Windows implementation of fractional scaling sometimes distort the positioning of UI elements a tiny bit, deviating them from 96dpi classic standard. But Wayland or GTK can study how web browsers do it then copy the method to desktop compositing or GUI drawing.

[Portreve]

So, here's something I don't understand. The modern day equivalent to Display PostScript is effectively built into all the major desktop environments (Gnome, KDE, Cinnamon, Mate, Xfce) so why the h@ll is this even a thing? Many desktop environments (including Gnome) have gone to the trouble of replacing a lot of UI graphics with vector-based data. From where I sit, this should fundamentally be no different than with a printer which can interpret PostScript data and render a printed (or in this case visually displayed) bitmap image of its maximum possible resolution, which is approximately 72 dpi for most picture tube displays, 96 dpi for most modern non-4K LCD panels, and 200-400 (or more) dpi for the 4K-type units. The fact that displays regularly display above 72 dpi (and, for pretty much all modern and decent smartphones and tablets, 200+ dpi) is not new; it's something which has been with us since before the discussion about HiDPI for computers even began. And now it's 2022 and we're still fiddling around with this? It's kind of ridiculous.

[billyswong]

UI graphics being vector-based doesn't solve the stubbornness of Wayland / GTK teams. They are positioning and sizing all their UI objects in unit of logical pixels and make them integer only. They refuse to translate each positioning and scale each sizing to fractional values and render them directly onto screen/window buffer. They insist that the only way to render everything correct is to oversize the buffer, render everything on that oversized buffer, then scale the whole buffer down.

... approximately 72 dpi for most picture tube displays, 96 dpi for most modern non-4K LCD panels, and 200-400 (or more) dpi for the 4K-type units. The fact that displays regularly display above 72 dpi (and, for pretty much all modern and decent smartphones and tablets, 200+ dpi) is not new; it's something which has been with us since before the discussion about HiDPI for computers even began.

If the actual statistics is like what you describe here, then Wayland / GTK team has won. A monitor below 100dpi doesn't need any scaling. A monitor around 200dpi only needs 200% scaling (non-fractional). A monitor above 200dpi can more easily endure a lack of scaling choice between 200% and 300%. But the reality is far far away from the ideal those developers imagined. The market is occupied by huge amount of 13" to 15" laptops with 1080p screens, and standalone 4K monitors that are between 27" and 32". All these are asking for fractional scaling, especially 150% scaling. Without efficient native 150% scaling, Linux distributions become power hungry and sometimes lagging or sluggish.

Another problem is their postrender rescaling method conflicts with subpixel antialiasing (also bitmap fonts and "hinting"). Perhaps because those designer-type people are all Apple fans, they don't feel any loss for losing subpixel antialiasing. Sometimes when outsiders complained such, they responded by lecturing people subpixel antialiasing is bad, grayscale antialiasing is the only proper antialiasing, you guys should have abandoned that Microsoft cheat anyway etc. They may not be worded as such but the aura is they are turning "Apple product is beautiful" from an observation or opinion to almost like an unquestionable axiom. They ignore the fact that Apple products almost never dominate the market >50%, or wave it away by thinking those people who don't use Apple make their decision only because of the price and never because of the design.

[rossdv8]

My thoughts, after designing web pages since the days of the Mosaic Browser, and manipulating graphics (artwork and photographs) since the early 90s are that too many existing developers started study or work at a time when dinosaurs still ruled the computer room.
We dinosaurs experienced the change from switches to keyboards, punched cards, punched tape, to CRT, and punched cards and punched tape to rudimentary devices that could 'print' to paper.
Add to that, the ability to retain stored data on magnetic wire (one of my early computers) and magnetic tape, then, wonder of wonders, magnetic disks, some of which weighed about a kilo (mine in 1982) and were more than a foot in diameter, more than an inch thick and still only held less that 10 Megabytes of data!

So it was people who were severely restricted by the hardware they had, that paved the way for our measurements of display and printer output today.
Really though, it is fifty years later, and with the technology we have today, why are we still designing and inflicting on users, display measurements that used to be only applicable to individual dots on a CRT screen, that we could see with the naked eye? Or defining printed output by the number of dots that could once be physically hammered into a piece of paper, through a lump of ribbon?

Display size shouldn't be described as 640 x 480 or 1920 x 1050. It should be described to the OS as inches x inches, or centimetres x centimetres, prefereably with the ratio matching popular display sizes, and output simply scaled accordingly using something like vector graphics, rather than the raster type that we seem to be stuck with.

Not that it makes much difference to me - I am on my last legs. But the new breed of OS and GUI designers, and those creating content for Mobile Apps should have a brand new standard to work with. My son had a degree in computing about 20 years ago, but chose to work in another field. During CoVid, he ended up stuck home in Australia, and completed a course and internship in Design and implementation of Apps for the Web.
I was almost horrified to see than apart from the 'pretty bits' using modern twists on CSS (most of which I use anyway) the bulk of web development hasn't seemed to advance in years.

[Petermint]

My experience of bad design is through people coming in from print where DPI might be important or relevant. Given that 1080p screens vary in size from 50mm to over 1000mm, you want a 1 pixel border to be on one pixel and not fuzzy through all that Apple/postscript style junk.

On the performance side, for fast scrolling of hundreds of thousands of lines, I want each line on one box, not inside something that is inside something that is ... And there should be no stupid slow CSS styling. Everything should be composed at compilation time.

[billyswong]

Display size shouldn't be described as 640 x 480 or 1920 x 1050. It should be described to the OS as inches x inches, or centimetres x centimetres, prefereably with the ratio matching popular display sizes, and output simply scaled accordingly using something like vector graphics, rather than the raster type that we seem to be stuck with.

It doesn't work because you DON'T WANT a line of text be shown in the same phsyical size across (a) phone screens, (b) laptop / desktop monitors, and (c) outdoor display walls / cinema projectors. You want their text size to be a < b < c. Therefore, logical pixel is going to stay in HTML/CSS, as it makes more sense than logical inch or logical cm. It is just that sizing everything to device pixel grid no longer works, while snapping everything to logical pixel grid also doesn't guarantee to produce the cleanest display result.

In current Android, the OS somehow communicates to apps the expected size of normal text and expected size of normal icons(images and buttons). With the two expected sizes user-configurable in OS-level, conformant apps can size their UI according to them and provide the best experience to users. In small screen phones, users may want to squeeze more text into UI. Meanwhile in big screen tablets, users may want text size be bigger by default. Icons and buttons size may be more stable, but different people may still prefer different sizes as everyone's fingers are born different.

[rossdv8]

For the last ten years I've had to design web sites for business that can scale between all displays from computer monitors of various aspect ratios, TV screens of all sizes including my own 55 inch 4k monitor that I use to do the last websites I still maintain, and that have to be equally seamlessly displayed and switch immediately between portrait and landscape on phones and tablets.

Surely if an old codger like me can do stuff like that for what amounts to 'fancy advertisements' for businesses, it can't be too difficult to apply the same general principles to designing a computer operating system that scales fluidly across devices.

[Portreve]

UI graphics being vector-based doesn't solve the stubbornness of Wayland / GTK teams.

If that's the case, then may I respectfully suggest it's time to abandon those ways of handling things?

They are positioning and sizing all their UI objects in unit of logical pixels and make them integer only. They refuse to translate each positioning and scale each sizing to fractional values and render them directly onto screen/window buffer. They insist that the only way to render everything correct is to oversize the buffer, render everything on that oversized buffer, then scale the whole buffer down.

I really can't speak to any of that as I have no knowledge of the back end of these things. What I would offer as strictly a view from the sidelines is that seems to me like an absolute s██t way of handling things. Not saying that through any expertise; it just doesn't seem like a good way for it to be done.

If the actual statistics is like what you describe here, then Wayland / GTK team has won. A monitor below 100dpi doesn't need any scaling. A monitor around 200dpi only needs 200% scaling (non-fractional). A monitor above 200dpi can more easily endure a lack of scaling choice between 200% and 300%. But the reality is far far away from the ideal those developers imagined. The market is occupied by huge amount of 13" to 15" laptops with 1080p screens, and standalone 4K monitors that are between 27" and 32". All these are asking for fractional scaling, especially 150% scaling. Without efficient native 150% scaling, Linux distributions become power hungry and sometimes lagging or sluggish.

Ditto my above comment here.

Another problem is their postrender rescaling method conflicts with subpixel antialiasing (also bitmap fonts and "hinting"). ...

To be fair, I've always really liked the way Gnome 1.x, 2.x, 3.x, and even KDE render fonts. A lot of that is informed by my previous professional experience in the world of desktop publishing. I've never liked the way Windows has rendered them. Yes, the current iteration of their ClearType subsystem does a decent job, but I still prefer Mac OS X's and GTK's/Qt's way of doing it.

My experience of bad design is through people coming in from print where DPI might be important or relevant. Given that 1080p screens vary in size from 50mm to over 1000mm, you want a 1 pixel border to be on one pixel and not fuzzy through all that Apple/postscript style junk.

I'm not a fan of that situation. I think the situation has gotten completely out of hand.

In my view, if things were done correctly, then absolutely everything that's not a photo could be and should be rendered via vector data rasterized in real time by the graphics card at the appropriate resolution for the monitor in question. And furthermore, I don't think that there should have to be such a thing as "scaling".

[MurphCID]

Portreve (and others) I cannot disagree at all, I think that the Linux graphics stacks need to have a lot of work. If I was able to code, that would be a project I would like. There is too darn much; "Not Invented Here!" syndrome, also a stubborn refusal to move on from "the way we have always done this" within the Linux world. But that is probably because Linux is not a desktop operating system no matter how hard we try, but a Server operating system at heart. It wants Big Iron to work right.

[billyswong]

Latest example of computer performance ruined by lack of native fractional scaling: viewtopic.php?f=47&t=385928

[billyswong]

In my view, if things were done correctly, then absolutely everything that's not a photo could be and should be rendered via vector data rasterized in real time by the graphics card at the appropriate resolution for the monitor in question. And furthermore, I don't think that there should have to be such a thing as "scaling".

For displaying non-vector images, we always need a way to determine if we should display it straight to the device pixels 1:1, or scale it up/down. Camera photos and recorder videos are not going to be vectorized natively in foreseeable future. So the concept of scaling is not going to go away even if all monitors in the world gain 300+dpi magically.

On one hand, there are no "correct" physical sizes for photos and videos. On the other hand, font design is logical size dependent. There is a minimum stroke width for readers to read comfortably, even if the monitor got a magical unlimited dpi. Thus in professional typesetting, font designed for "small" text and font designed for "big" titles are different. The minimum stroke width is somehow a function of how many (fractions of) degrees of our eyesight. When text shrink, the heaviest strokes can shrink proportionally but the thinnest strokes can't or it will hinder readability even for extremely Hi-DPI screen.

p.s. It is not the official definition but some people did define "logical pixel" in terms of angle.

[MurphCID]

Some really good information in this thread. Perhaps Gnome needs to spend more time working to get GTK mature, and flexible instead of running off after the "next new thing"?

[billyswong]

Some really good information in this thread. Perhaps Gnome needs to spend more time working to get GTK mature, and flexible instead of running off after the "next new thing"?

In their eyes, they have compromised a lot already. Initially some of their attitude were like "Fractional scaling is an ugly hack. We won't let such ugly hack in our code base. Don't buy monitors or laptops that ask for fractional scaling if you want to use our beautiful system."

Good news is, now pressure from KDE side is pushing Wayland to support fractional scaling in a more native manner. Hope is not all lost.

[MurphCID]

Some really good information in this thread. Perhaps Gnome needs to spend more time working to get GTK mature, and flexible instead of running off after the "next new thing"?

In their eyes, they have compromised a lot already. Initially some of their attitude were like "Fractional scaling is an ugly hack. We won't let such ugly hack in our code base. Don't buy monitors or laptops that ask for fractional scaling if you want to use our beautiful system."

Good news is, now pressure from KDE side is pushing Wayland to support fractional scaling in a more native manner. Hope is not all lost.

Yeah "Not invented here" syndrome on full display. Plus the Gnome team reportedly does not play well with others. Perhaps a little Atlas Shrugged is needed?

[ivar]

Latest example of computer performance ruined by lack of native fractional scaling: viewtopic.php?f=47&t=385928

Very interesting,
I've noticed my good ol' yoga running hot and maxing out cpu much more after upgrading to LM 21. With 3200x1800 resolution and 150% scaling it was struggling to keep up, especially when playing video. Went back to 200% after reading the linked thread, and the poor yoga is running much cooler

[MurphCID]

Latest example of computer performance ruined by lack of native fractional scaling: viewtopic.php?f=47&t=385928

Very interesting,
I've noticed my good ol' yoga running hot and maxing out cpu much more after upgrading to LM 21. With 3200x1800 resolution and 150% scaling it was struggling to keep up, especially when playing video. Went back to 200% after reading the linked thread, and the poor yoga is running much cooler

That should NEVER happen in a 2022 OS.

[Petermint]

and the poor yoga is running much cooler

What is the hardware where that happens? Does your machine have a GPU? The cost of graphics is not visible in my current fast machine. It might be something to include in advice for owners of older or lower cost machines.

[MurphCID]

I would like larger scroll bars...

[rossdv8]

I would like larger scroll bars...

That's one of the reasons I kept coming back to Xfce. I get to have big bright buttons on more or less any window decoration theme, large borders that I can grab easily and nice thick scroll bards on 'most' windows that scroll. And even on Firefox I found an extension that lets me have scroll bars I can actually find.

Annoyingly, I just installed Mint 21 on my spare computer so I could have one machine with a 'fresh' install for the first time in a couple of years.
Now I have to do all the theming again