Ancient X11 scaling technology • Hacker News Board

Re: Ancient X11 scaling technology

#261

Post by lproven » Thu, Jun 26, 2025, 3:47 PM UTC

const_cast wrote: post #255

account42 wrote: post #236

Earlier quoted context omitted.

Well the pragmatic take of many users (myself included) is to stick with X11 because Wayland absolutely is not a polished product and likely won't be before being declared obsolete by the NIH crowd. Of course, newer KWin versions also add many odd issues with X11 so I'm sure they will bug equally buggy soon enough and users can finally switch without such concerns. > The most close analogue I can think of that most i…

Wayland is significantly more polished than X on my experience on new hardware. Everything, literally everything, works and looks better. X, in comparison, seems almost plagued with a thin layer of jank over the whole thing. X has been on life support for decades now, with new capabilities just bolted on without a care in the world. But the actual system works quite inconsistently, and some things will, presumably, n…

> Everything, literally everything, works

I keep hearing this.

My preferred desktop is Unity. I also like the ROX desktop, and Openbox, and I used to like EDE and XPde. I find CDE interesting to play with and want to try the Maxx Interactive Desktop, a version of SGI's IRIX desktop. LXDE was clunky but it worked for me, but LXQt isn't: its vertical taskbar has been broken since before version 1.0.

Not one of those working environments can use Wayland, and all of them are unlikely ever to.

I detest KDE, which I find horribly overcluttered and messily inconsistent, and I also detest GNOME >=3 which feels like a phone UI on a desktop: it's missing almost every option I want. They are two extremes, one overly complicated, one overly minimal. I do not use the shell much so I have no interest in tiling environments.

There's not a single environment I find bearable on Wayland today. Maybe, by 2027, there will be a usable Xfce.

In other words, in terms that matter to me personally, Wayland is not better in any way whatsoever, and nothing I use works.

I say this not to be confrontational, but merely to point out while one person can say "but everything works!" the claim can be true for them while not generalising at all.

Re: Ancient X11 scaling technology

#262

Post by dontlaugh » Thu, Jun 26, 2025, 4:52 PM UTC

lotharcable wrote: post #249

dontlaugh wrote: post #180

Earlier quoted context omitted.

I've found the opposite, that only macOS handles that perfectly. Windows still breaks in several situations like different size and density monitors, but it's generally good enough. Recent Gnome on Wayland does about as well as Windows.

Windows is the only platform that tries to do it "correctly" as per the internet peanut gallery. And, of course, doing it "wrongly" as per what OS X and Gnome does works a lot better in practice.

I don't know what Gnome does differently from macOS, but moving a window between screens of different density doesn't behave as expected. macOS gets this right, Windows doesn't either.

Re: Ancient X11 scaling technology

#263

Post by account42 » Fri, Jun 27, 2025, 8:03 AM UTC

kccqzy wrote: post #245

account42 wrote: post #220

Earlier quoted context omitted.

It mostly works but you can still run into issues when you e.g. want to have an element size match the border of another. Things like that that used to work don't anymore due to the tricks needed to make fractional scaling work well enough for other uses.

Why wouldn't it work? The border-size accepts the same kind of length units as height or width, no?

The problem is the rounding from fractional sizes due to fractional scaling to whole pixel sizes needed to keep things looking crisp. Browsers try really hard to make sure that during this process all borders of an element remain the same size, but this also means that they end up introducing inconsistencies with other measurements.

Re: Ancient X11 scaling technology

#264

Post by simoncion » Fri, Jun 27, 2025, 8:28 AM UTC

LionEgo wrote: post #251

simoncion wrote: post #216

Earlier quoted context omitted.

> Same browser, same browser settings, same OS and same plugins. Neat. Did you test outside of the browser? Based on your report, it sounds like you didn't. As you must know, the renderers in web browsers are very, very complex. I suggest you test with a standalone video player before you go blaming the underlying windowing system for performance issues.

[flagged]

> You have to explain to me how it couldn't have been the window system giving me the uplift in video playback in the browser...

My instance of Firefox has been configured to use only software rendering. This YouTube video https://www.youtube.com/watch?v=tO01J-M3g0U> runs fine in both Firefox and mpv. This YouTube video https://www.youtube.com/watch?v=WjoplqS1u18> drops many frames when played at 8K in Firefox (making it choppy and sluggish), but zero when played at 8K in mpv.

There are a great many variables in play when playing something through a web browser. That's why I suggested you re-run the test without the web browser.

Speaking of "a great many variables"...

> The machine went to sluggish and painful to use, to being reasonably decent.

Then something seems to be wrong with your Xorg config. Whether it's the drivers, the configuration of the system, or both, I don't have enough information to know. Are you running Xorg on an ARM Apple machine? That's apparently known to work very, very poorly because Apple's graphics hardware is "special". Are you running an un-accelerated Xorg video driver (like the VESA or fbdev drivers) or are perhaps using the nouveau driver on Nvidia hardware? The former would certainly be very slow. The latter is known to work fine for some folks and work really, really poorly for others.

> I don't appreciate your snark.

It's not snark. It's an earnest request to reduce the number of moving parts to make troubleshooting easier. And (as we've discovered from further testimony) the web browser wasn't even involved in the slowness... the problem is a misconfiguration of your Xorg install. We would have discovered this if you'd run the requested test, but incidental self-report works just as well.