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

131–140 of 264 posts

Re: Ancient X11 scaling technology

#131

Post by slackfan »

kllrnohj wrote: post #122
phkahler wrote: post #13

Earlier quoted context omitted.

>> The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry. And doing so actually using X not OpenGL.

Yeah this is kinda the big elephant in the room here? They didn't prove what they set out to prove. Yes obviously OpenGL does scaling just fine, the entire point of Wayland is to get the compositor to just being a compositor. They didn't do any scaling with X. They didn't do anything at all with X other than ask it some basic display information.

X shouldn't be displaying anything that isn't a right angle anyway.

All circular UI elements are haram.

Re: Ancient X11 scaling technology

#132

Post by sho_hn »

maxdamantus wrote: post #110
sho_hn wrote: post #29

Earlier quoted context omitted.

> 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…

The "It did" was about the mechanism (Wayland did tell the clients the scale and expected them to render acccordingly). Yes, fractional wasn't in the core protocol at the start, but that wasn't the object of discussion (it was elsewhere, as you can see in the sibling threads that evolved, where I also totally agree this was a huge wart).

Re: Ancient X11 scaling technology

#133

Post by cycomanic »

sho_hn wrote: post #81
cycomanic wrote: post #71

Earlier quoted context omitted.

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.

The end-user UIs don't ask you to calculate anything. Typically they have a slider from 100% to, say, 400% and let you set this to something like 145%. This may take some getting used to if you're familiar with DPI and already know the value you like, but for non-technical users it's more approachable. Not everyone knows DPI or how many dots they want to their inches. That the 145% is 1.45 under the hood is really an…

I don't care about what we call the metric, I argue that a relative metric, where the reference point is device dependent is simply bad design.

I challenge you, tell a non-technical user to set two monitors (e.g. laptop and external) to display text/windows at the same size. I will guarantee you that it will take them significant amount of time moving those relative sliders around. If we had an absolute metric it would be trivial. Similarly, for people who regularly plug into different monitors, they would simply set a desired DPI and everywhere they plug into things would look the same instead of having to open the scale menu every time.

Re: Ancient X11 scaling technology

#134

Post by sho_hn »

bscphil wrote: post #126
sho_hn wrote: post #94

Earlier quoted context omitted.

You're overthinking things a bit and are also a bit confused about how font sizes work and what "scaling" means in a windowing system context. You are thinking taking a bunch of pixels and resampling. In the context we're talking about "scaling" means telling the software what it's expected to output and giving it an opportunity to render accordingly. The way the terminal handles the (literal) edge case you mention i…

Given that the context here is talking about terminals, they probably are literally thinking in terms of bitmap based rendering with integer scaling.

Right, but most users of terminal emulators typically don't use bitmap fonts anymore and haven't for quite some time (just adding this for general clarity, I'm sure you know it).

Re: Ancient X11 scaling technology

#135

Post by sho_hn »

cycomanic wrote: post #133
sho_hn wrote: post #81

Earlier quoted context omitted.

The end-user UIs don't ask you to calculate anything. Typically they have a slider from 100% to, say, 400% and let you set this to something like 145%. This may take some getting used to if you're familiar with DPI and already know the value you like, but for non-technical users it's more approachable. Not everyone knows DPI or how many dots they want to their inches. That the 145% is 1.45 under the hood is really an…

I don't care about what we call the metric, I argue that a relative metric, where the reference point is device dependent is simply bad design. I challenge you, tell a non-technical user to set two monitors (e.g. laptop and external) to display text/windows at the same size. I will guarantee you that it will take them significant amount of time moving those relative sliders around. If we had an absolute metric it wou…

I see where you are coming from and it makes sense.

I will also say though that in the most common cases where people request mixed scale factor support from us (laptop vs. docked screen, screen vs. TV) there are also other form factor differences such as viewing distance that doesn't make folks want to match DPI, and "I want things bigger/smaller there" is difficult to respond to with "calculate what that means to you in terms of DPI".

For the case "I have two 27" monitors side-by-side and only one of them is 4K and I want things to be the same size on them" I feel like the UI offering a "Match scale" action/suggestion and then still offering a single scale slider when it sees that scenario might be a nice approach.

Re: Ancient X11 scaling technology

#136

Post by erlkonig »

This whole issue just seems so pathetic. PostScript and DPS, notably NeWS, have device-independent scaling from the outset - you can completely omit even mentioning pixels, even though they're 2D. Wayland braying on about scalability here just highlights how they don't even understand the game.

Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway.

I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.

Re: Ancient X11 scaling technology

#137

Post by Qwertious »

DonHopkins wrote: post #26
arp242 wrote: post #24

Earlier quoted context omitted.

[flagged]

[flagged]

>Somebody just ASKED me to post more information, and they were even so kind as to say "please", so I did. If you object to that, then there is a "next" link you can press to skip over it without wasting your time replying! If that's too difficult and your panties are still in a bunch about my posting replies to legitimate questions, then take it up with sprash for asking. Happy clicking and toxic whining!

Oh shit, is that what the "next" button is for? TYVM, and I mean that unironically.

Re: Ancient X11 scaling technology

#138

Post by DonHopkins »

xioxox wrote: post #36
kunzhi wrote: post #25

Interesting article, I'll admit when I first saw the title I was thinking of a different kind of "scaling" - namely the client/server decoupling in X11. I still think X11 forwarding over SSH is a super cool and unsung/undersung feature. I know there are plenty of good reasons we don't really "do it these days" but I have had some good experiences where running the UI of a server app locally was useful. (Okay, it was…

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).

I worked on the NeWS drivers for Emacs (both "Evil Software Hoarder" Gosling UniPress Emacs 2.20 and later "Free" Gnu Emacs 18), which were extremely efficient and smoothly interactive over low baud rate modems (which we called "thin wire" as opposed to i.e. the "thick wire" coaxial 10BASE5 Ethernet of the time), because instead of using the extraordinarily inefficient, chatty, pong-pongy X-Windows protocol, Emacs could simply download PostScript code to the window server that defined a highly optimized application specific client/server protocol and intelligent front-end (now termed "AJAX"), which performed as much real time interaction in the window system as possible, without any network activity, like popping up and tracking pie menus, and providing real time feedback and autoscroll when selecting and highlighting text.

For example, both versions of Emacs would download the lengths of each line on the screen when you started a selection, so you could drag and select the text and animation the selection overlay without any network traffic at all, without sending mouse move events over the network, only sending messages when you autoscrolled or released the button.

http://www.bitsavers.org/pdf/sun/NeWS/800-5543-10_The_NeWS_T... document page 2, pdf page 36:

>Thin wire

>TNT programs perform well over low bandwidth client-server connections such as telephone lines or overloaded networks because the OPEN LOOK components live in the window server and interact with the user without involving the client program at all.

>Application programmers can take advantage of the programmable server in this way as well. For example, you can download user-interaction code that animates some operation.

UniPress Emacs NeWS Driver:

https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7...

Selection support with local feedback:

https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7...

Gnu Emacs 18 NeWS Driver (search for LocalSelectionStart):

https://donhopkins.com/home/code/emacs18/src/tnt.ps

https://news.ycombinator.com/item?id=26113192

DonHopkins on Feb 12, 2021 | parent | context | favorite | on: Interview with Bill Joy (1984)

>Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun. https://en.wikipedia.org/wiki/Gosling_Emacs

>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.

>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"

>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."

>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!

In the late 80's, if you had a fast LAN and not a lot of memory and disk (like a 4 meg "dickless" Sun 3/50), it actually was more efficient to run X11 Emacs and even the X11 window manager itself over the LAN on another workstation than on your own, because then you didn't suffer from frequent context switches and paging every keystroke and mouse movement and click.

The X11 server and Emacs and WM didn't need to context switch to simply send messages over the network and paint the screen if you ran emacs and the WM remotely, so Emacs and the WM weren't constantly fighting with the X11 server for memory and CPU. Context switches were really expensive on a 68k workstation, and the way X11 is designed, especially with its outboard window manager, context switching from ping-ponging messages back and forth and back and forth and back and forth and back and forth between X11 and the WM and X11 and Emacs every keystroke or mouse movement or click or window event KILLED performance and caused huge amounts of virtual memory thrashing and costly context switching.

Of course NeWS eliminated all that nonsense gatling gun network ping-ponging and context switching, which was the whole point of its design.

That's the same reason using client-side Google Maps via AJAX of 20 years ago was so much better than the server-side Xerox PARC Map Viewer via http of 32 years ago.

https://en.wikipedia.org/wiki/Xerox_PARC_Map_Viewer

Outboard X11 ICCCM window managers are the worst possible most inefficient way you could ever possibly design a window manager, and that's not even touching on their extreme complexity and interoperability problems. It's the one program you NEED to be running in the same context as the window system to synchronously and seamlessly handle events without dropping them on the floor and deadlocking (google "X11 server grab" if you don't get what this means), but instead X11 brutally slices the server and window manager apart like King Solomon following through with his child-sharing strategy.

https://tronche.com/gui/x/xlib/window-and-session-manager/XG...

While NeWS not only runs the window manager efficiently in the server without any context switching or network overhead, but it also lets you easily plug in your own customized window frames (with tabs and pie menus), implement fancy features like rooms and virtual scrolling desktops, and all kinds of cool stuff! At Sun were even managing X11 windows with a NeWS ICCCM window manager written in PostScript, wrapping tabbed windows with pie menus around your X-Windows!

https://donhopkins.com/home/archive/NeWS/owm.ps.txt

https://donhopkins.com/home/archive/NeWS/win/xwm.ps

https://www.donhopkins.com/home/catalog/unix-haters/x-window...

Re: Ancient X11 scaling technology

#139

Post by pwnna »

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…

So I don't understand where the meme of the blurry super-resolution based down sampling comes from. If that is the case, what is super-resolution antialiasing[1] then? Images when rendered at higher resolution than downsampled is usually sharper than an image rendered at the downsampled resolution. This is because it will preserve the high frequency component of the signal better. There are multiple other downsampling-based anti-aliasing technique which all will boost signal-to-noise ratio. Does this not work for UI as well? Most of it is vector graphics. Bitmap icons will need to be updated but the rest of UI (text) should be sharp.

I know people mention 1 pixel lines (perfectly horizontal or vertical). Then they go multiply by 1.25 or whatever and go like: oh look 0.25 pixel is a lie therefore fractional scaling is fake (sway documentation mentions this to this day). This doesn't seem like it holds in practice other than from this very niche mental exercise. At sufficiently high resolution, which is the case for the display we are talking about, do you even want 1 pixel lines? It will be barely visible. I have this problem now on Linux. Further, if the line is draggable, the click zones becomes too small as well. You probably want something that is of some physical dimension which will probably take multiple pixels anyways. At that point you probably want some antialiasing that you won't be able to see anyways. Further, single pixel lines don't have to be exactly the color the program prescribed anyway. Most of the perfectly horizontal and vertical lines on my screen are all grey-ish. Having some AA artifacts will change its color slightly but don't think it will have material impact. If this is the case, then super resolution should work pretty well.

Then really what you want is something as follows:

1. Super-resolution scaling for most "desktop" applications.

2. Give the native resolution to some full screen applications (games, video playback), and possibly give the native resolution of a rectangle on screen to applications like video playback. This avoids rendering at a higher resolution then downsampling which can introduce information loss for these applications.

3. Now do this on a per-application basis, instead of per-session basis. No Linux DE implements this. KDE implements per-session which is not flexible enough. You have to do it for each application on launch.

[1]: https://en.wikipedia.org/wiki/Supersampling

Re: Ancient X11 scaling technology

#140

Post by sho_hn »

bscphil wrote: post #128
ndiddy wrote: post #31

Earlier quoted context omitted.

Wayland has supported X11 style fractional scaling since 2022: https://wayland.app/protocols/fractional-scale-v1 . Both Qt and GTK support fractional scaling on Wayland.

Rather annoyingly, the compositor support table on this page seems to be showing only the latest version of each compositor (plus or minus a month or two, e.g. it's behind on KWin). I assume support for the protocol predates these versions for the most part? Do you know when the first versions of KDE and Gnome to support the protocol were released? Asking because some folks in this thread have claimed that a large ma…

We first shipped support for wp-fractional-scale-v1 in Plasma 5.27 in early 2023, support for it in our own software vastly improved with Plasma 6 (and Qt 6) however.
Post reply on HN