Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ancient X11 scaling technology

flak.tedunangst.com

Post reply on HN
Print view View original

201–210 of 264 posts

Re: Ancient X11 scaling technology

#201

Post by crest »

pedrocr wrote: post #4

That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in…

If you did it right you would render the damaged area of each window for each display it's visible on, but that would require more rigerous engineering than our software stacks have.

Re: Ancient X11 scaling technology

#202

Post by jchw »

zozbot234 wrote: post #169
jchw wrote: post #127

Earlier quoted context omitted.

Using vector pipelines isn't new, of course: Windows has been doing DPI-independent rendering since almost the beginning with GDI. The actual issue with GDI's scaling is all about text: for something to be "scalable" it has to maintain its proportions when the scale factor changes, but this was not the case for text in Win32/GDI, due to pixel grid fitting. Because of this, it was common in the Windows XP era to see i…

> Because of this, it was common in the Windows XP era to see ill-sized text when changing the DPI to anything other than 96, resulting in things being cut off and generally broken. The underlying issue with this is the use of fixed-layout interfaces in Win32. If you tweak the layout dynamically to be "responsive" to how the text wraps, this becomes an absolute non-issue. It could also be done with reasonable efficie…

While that is a solution for this specific issue, it doesn't solve everything. It's better to both have proper layout and proper proportional fonts at the same time.

Re: Ancient X11 scaling technology

#203

Post by jchw »

kelnos wrote: post #154
jchw wrote: post #74

Earlier quoted context omitted.

> It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Ex…

> Accurate DPI information is insufficient as users may want to scale differently anyways, either due to preference, higher viewing distance, or disability. Which is fine. There's already a standardized property in XSETTINGS to use on X11 to advertise the user's scaling preference. For Wayland they decided to include this into the protocol, so it can be per-output and/or per-window (though the per-window fractional s…

The issue is that if you want DPI virtualization, and all of the desktops do want that, you need to be able to translate all of the coordinate spaces everywhere. If you try to integrate this into X11, you run into a myriad of different problems that are just not that easy to solve. It was direct inspiration for some of the design elements in Wayland.

The same folks who are working on Wayland today did a lot of work to get X.org to where it is now. They could do more, but the writing was on the wall.

Re: Ancient X11 scaling technology

#204

Post by AlienRobot »

amiga386 wrote: post #90

It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"

I'm struggling to imagine why would anyone ever want to do that. It's not even an edge case at this point, it's over the edge.

Re: Ancient X11 scaling technology

#205

Post by jchw »

archy_ wrote: post #148
jchw wrote: post #74

Earlier quoted context omitted.

> It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Ex…

>users may want to scale differently anyways Users think they want a lot of things they don't really need. Do we really want to hand users that loaded gun so that they can choose incorrectly where to fire?

No. This is an actual real issue.

For example, if I'm using KDE on a TV, which by the way I am (with Bazzite to be exact, works great) then I want to set the scale factor in KDE higher because I'm going to be standing further away. This is not optional; the UI is completely unreadable if you just let it use the physical dimensions to scale. There's nothing you can do. A preference is necessary to handle this case.

You could argue that this is a PEBKEC ignoring the fact that desktop environments care about this use case, but what you can't argue about is this: it's an accessibility issue. Having a magnifier tool is very important for people who have vision issues, but it is not enough. Users with vision problems need to be able to scale the UI. And yes, the UI, not text size. Changing the text size helps for text, but not for things like icons.

If you want to be able to sell Linux on devices in the EU, then having sufficient accessibility features is not optional.

Re: Ancient X11 scaling technology

#206

Post by welterde »

inetknght wrote: post #119
xioxox wrote: post #36

Earlier quoted context omitted.

It's certainly very useful. I do half my work using X11 over ssh and it works reasonably well over a LAN (at least using emacs, plotting, etc).

"reasonably well" as in... yeah it works. But it's extremely laggy (for comparison, I know people who forwarded DirectX calls over 10Mbit ethernet and could get ~15 frames/sec playing Unreal Tournament in the early 00's), and any network blip is liable to cause a window that you can neither interact with nor forcefully close. It felt like a prototype feature that never became production-ready for that reason alone. T…

For applications that were written with X11 in mind it works much much better than that. One example was the controlling a telescope. The computers in the control room were thin clients pretty much and displayed various windows from various machines across the mountain - even across multiple different operating systems! Some machines were running Solaris and some linux. The different machines belonged to different aspects of the telescope: some controlled the telescope itself and some machines belonged to the different scientifc instruments on the telescope. And it all worked quite well with no real noticeable lag.

Re: Ancient X11 scaling technology

#207

Post by rbanffy »

em-bee wrote: post #176
kelnos wrote: post #151

Earlier quoted context omitted.

You can absolutely do that on X11, but you have to do it in the client, and no one cares to do it.

if you have to do it in the client, aka the application, then it's not transparent to the application

It'll not be transparent to an application using basic X APIs, but nothing prevents a higher level UI toolkit from implementing it properly.

Re: Ancient X11 scaling technology

#208

Post by rbanffy »

AlienRobot wrote: post #204
amiga386 wrote: post #90

It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"

I'm struggling to imagine why would anyone ever want to do that. It's not even an edge case at this point, it's over the edge.

It happens. You might push a window aside so that it's partially on a second screen and still see activity on the second screen. It should be the expected behavior.

Re: Ancient X11 scaling technology

#209

Post by Boxxed »

kelnos wrote: post #152
denkmoon wrote: post #80

Earlier quoted context omitted.

Multi monitor with mixed DPIs absolutely does not work well in x11 in 2025. I don’t know about 20+ years ago.

It could , though. GTK has support for mixed DPI, just only for Wayland. There's no reason why it couldn't work on X11. It might be more tricky to get right, but it's just a matter of work.

"just a matter of work."

Yeah, like every other conceivable feature, ever.

Re: Ancient X11 scaling technology

#210

Post by LionEgo »

simoncion wrote: post #193
LionEgo wrote: post #182

Earlier quoted context omitted.

It depends on the game/application and what you are running and your distro may have enabled TearFree for you. I use Debian and it isn't enabled by default. If I was to play Dark Souls 3 and/or Elden ring on Linux without tearfree. There is significant screen tearing and the game feels very choppy when playing. To enable TearFree on Xorg. You typically make a new configuration file that sits in /etc/X11/xorg.conf.d/…

> (it is the video itself not YouTube being a resource hog, I checked) Did you check by downloading the video and playing it with a good standalone video player like mplayer, vlc, or mpv? If you didn't, then you didn't disentangle the web browser from the video playback.

I've spent a lot of time in my career working on weird rendering issues on websites/devices. Believe me when I said "I checked", I know WTF I am talking about.

The only thing that was different was Wayland vs X11. Same browser, same browser settings, same OS and same plugins.

Post reply on HN