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

101–110 of 264 posts

Re: Ancient X11 scaling technology

#101

Post by sho_hn »

0x457 wrote: post #100
sho_hn wrote: post #91

Earlier quoted context omitted.

It's in Wayland in the same way everything else is, i.e. fractional scaling is now a protocol included in the standard protocol suite. > Because what is probably 90% of wayland install base only supports communicating integer scales to clients. As someone shipping a couple of million cars per year running Wayland, the install base is a lot bigger than you think it is :)

Hmmm, sorry, but I don't care about install base of wayland in a highly controlled environment (how many different monitor panels you ship is probably less amount of displays with different DPI in my living room right now).

90% is still nonsense even in desktop Linux, tho.

Re: Ancient X11 scaling technology

#102

Post by MadnessASAP »

cycomanic wrote: post #71
zokier wrote: post #49

Earlier quoted context omitted.

> That's still mostly the case in what's shipping right now I believe All major compositors support fractional scaling extension these days which allows pixel perfect rendering afaik, and I believe Qt6 and GTK4 also support it. https://wayland.app/protocols/fractional-scale-v1#compositor...

That's great, however why do we use a "scale factor" in the first place? We had a perfectly fitting metric in DPI, why can't I set the desired DPI for every monitor, but instead need to calculate some arbitrary scale factor? I'm generally a strong wayland proponent and believe it's a big step forward over X in many ways, but some decisions just make me scratch my head.

I'm not privy to what discussions happened during the protocol development. However using scale within the protocol seems more practical to me.

Not all displays accurately report their DPI (or can, such as projectors). Not all users, such as myself, know their monitors DPI. Finally the scaling algorithm will ultimately use a scale factor, so at a protocol level that might as well be what is passed.

There is of course nothing stopping a display management widget/settings page/application from asking for DPI and then converting it to a scale factor, I just don't known of any that exist.

Re: Ancient X11 scaling technology

#103

Post by zozbot234 »

BearOso wrote: post #93
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…

I think having any kind of "scaling" preferences focuses too much on the technical aspect. It could be narrowed down to one setting like "zoom level" or just "size." This would mean that all UI elements change size exactly proportionately to one another. Ideally, rendering should happen at the exact resolution of the display, and scaling, as in resizing a bitmap using bilinear interpolation or whatever, doesn't need…

> Windows mostly does this, too, even with win32 as long as you're using the newer themes.

Win32 controls have always been DPI independent, as far back as Windows 95. There is DPI choice UX as part of the "advanced" display settings.

Re: Ancient X11 scaling technology

#104

Post by [deleted] »

wmf wrote: post #30
zozbot234 wrote: post #23

Earlier quoted context omitted.

Isn't OS X graphics supposed to be based on Display Postscript/PDF technology throughout? Why does it have to render at 2x and downsample, instead of simply rendering vector-based primitives at native resolution?

No, I think integer coordinates are pervasive in Carbon and maybe even Cocoa. To do fractional scaling "properly" you need to use floating point coordinates everywhere.

[deleted]

Re: Ancient X11 scaling technology

#105

Post by kalleboo »

wmf wrote: post #30
zozbot234 wrote: post #23

Earlier quoted context omitted.

Isn't OS X graphics supposed to be based on Display Postscript/PDF technology throughout? Why does it have to render at 2x and downsample, instead of simply rendering vector-based primitives at native resolution?

No, I think integer coordinates are pervasive in Carbon and maybe even Cocoa. To do fractional scaling "properly" you need to use floating point coordinates everywhere.

Cocoa/Quartz 2D/Core Graphics uses floating-point coordinates everywhere and drawing is resolution-independent (e.g., the exact same drawing commands are used for screen vs print). Apple used to tout OS X drawing was "based on PDF" but I think that only meant it had the same drawing primitives and could be captured in a PDF output context.

QuickDraw in Carbon was included to allow for porting MacOS 9 apps, was always discouraged, and is long gone today (it was never supported in 64-bit).

Re: Ancient X11 scaling technology

#106

Post by okanat »

Avamander wrote: post #98
okanat wrote: post #38

Earlier quoted context omitted.

And also doing it for multiple monitors with differing scales. Nobody claims X11 doesn't support different DPIs. The problems occur when you have monitors with differing pixel densities. At the moment only Windows handles that use case perfectly, not even macOS. Wayland comes second if the optional fractional scaling is implemented by the toolkit and the compositor. I am skeptical of the Linux desktop ecosystem to do…

Where does Windows handle it? It's a hodgepodge of different frameworks that often look absolutely abysmal at any scale besides 100%.

Every UI framework that runs on Windows has to communicate using Win32 API at the lowest level. Here is the guide: https://learn.microsoft.com/en-us/windows/win32/hidpi/high-d...

Every GUI application on Windows runs an infinite event loop. In that loop you handle messages like [WM_INPUT](https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-...). With Windows 8, Microsoft added a new message type: [WM_DPICHANGED](https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpi...). To not break the existing applications with an unknown message, Windows requires the applications to opt-in. The application needs to report its DPI awareness using the function [SetProcessDpiAwareness](https://learn.microsoft.com/en-us/windows/win32/api/shellsca...). The setting of the DPI awareness state can also be done by attaching an XML manifest file to the .exe file.

With the message Windows not only provides the exact DPI to render the Window contents for the display but also the size of the window rectangle for the perfect pixel alignment and to prevent weird behavior while switching displays. After receiving the DPI, it is up to application to draw things at that DPI however it desires. The OS has no direct access to dictate how it is drawn but it does provide lots of helper libraries and functions for font rendering and for classic Windows UI elements.

If the application is using a Microsoft-implemented .NET UX library (WinForms, WPF or UWP), Microsoft has already implemented the redrawing functions. You only need to include manifest file into the .exe resources.

After all of this implementation, why does one get blurry apps? Because those applications don't opt in to handle WM_DPICHANGED. So, the only option that's left for Windows is to let the application to draw itself at the default DPI and then stretch its image. Windows will map the input messages to the default DPI pixel positions.

Microsoft does provide a half way between a fully DPI aware app and an unaware app, if the app uses the old Windows resource files to store the UI in the .exe resources. Since those apps are guaranteed to use Windows standard UI elements, Windows can intercept the drawing functions and at least draw the standard controls with the correct DPI. That's called "system aware". Since it is intercepting the application's way of drawing, it may result in weird UI bugs though.

Re: Ancient X11 scaling technology

#107

Post by nullc »

rwmj wrote: post #46

It's like the "oh no, X11 suffers from tearing video" problem that they pull out all the time. (A) I have no idea what "video tear" is and (B) I play video all the time on my crappy laptop running X11 and it seems fine for me. But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously.

If someone shows it to you, you'll recognize it. It's when one frame shows part of the prior frame and part of the next. It's most visible in moderate speed horizontal pans as an interruption in vertical lines in the picture.

It's nice to not have tearing. But IMO the functionality loss vs X11 isn't worth it for anything but a dedicated media playback/editing device.

Re: Ancient X11 scaling technology

#108

Post by nullc »

compiler-devel wrote: post #57

Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local…

> Yes, it was slow,

Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet.

And even on a fast network the wayland alternative of 'use RDP' is almost unusable.

Re: Ancient X11 scaling technology

#109

Post by jekwoooooe »

throw39304949 wrote: post #70
jekwoooooe wrote: post #54

It’s astounding to me that in Linux, in 2025, I can’t just simply output a custom resolution. You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. I can’t even scale my screen within a normal resolution to make it fit within a boundary. But I can do this in windows with an nvidis gpu. Crazy

[flagged]

Nope I can output 4k just fine. That’s not the issue. The issue is I want a 2.35:1 aspect resolution. I can do this on windows and nvidia but not on Linux (steam deck, intel nuc, etc)

Re: Ancient X11 scaling technology

#110

Post by maxdamantus »

sho_hn wrote: post #29
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…

> doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux Linux does not do that. > It's strange that Wayland didn't do it this way from the start It did (initially for integer scale factors, later also for fractional ones, though some Wayland-based environments did it earlier downstream).

> Linux does not do that.

It did (or at least Wayland compositors did).

> It did

It didn't.

I complained about this a few years ago on HN [0], and produced some screenshots [1] demonstrating the scaling artifacts resulting from fractional scaling (1.25).

This was before fractional scaling existed in the Wayland protocol, so I assume that if I try it again today with updated software I won't observe the issue (though I haven't tried yet).

In some of my posts from [0] I explain why it might not matter that much to most people, but essentially, modern font rendering already blurs text [2], so further blurring isn't that noticable.

[0] https://news.ycombinator.com/item?id=32021261

[1] https://news.ycombinator.com/item?id=32024677

[2] https://news.ycombinator.com/item?id=43418227

Post reply on HN