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

111–120 of 264 posts

Re: Ancient X11 scaling technology

#111

Post by DonHopkins »

sprash wrote: post #69
DonHopkins wrote: post #34

Earlier quoted context omitted.

Since they bought Sun Microsystems, Oracle now owns the rights to the NeWS source code, so unfortunately I'm not legally allowed to post the NeWS server source code on my Github page, although I spent many years unsuccessfully fighting to make NeWS free and evangelizing it to anyone who would listen, like RMS and my colleagues and customers at Sun: https://www.donhopkins.com/home/archive/NeWS/rms.news.txt https://www…

> Oracle owns the rights to the NeWS source code so I'm not allowed to post it on my Github page. They are certainly not making any money with it right now. All patents should be expired by now. Have you ever sincerely asked if you are allowed to publish the code? > Do you have any ... display servers that solve all the problems too? X11 has extensions which correct for most of its original flaws. Most importantly XR…

>> Oracle owns the rights to the NeWS source code so I'm not allowed to post it on my Github page.

>They are certainly not making any money with it right now. All patents should be expired by now. Have you ever sincerely asked if you are allowed to publish the code?

Ha ha! Good luck, kiddo. Have you ever tried asking a lawnmower for favors? Do you really think "sincerity" would help?

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

https://youtu.be/-zRN7XLCRhc?t=33m1s

>X11 has extensions which correct for most of its original flaws.

Oh, then I guess there's no reason for Wayland, then. Have you broken the news to them? How did they react?

So is there an X-Windows extension yet that lets you download code into the window server where it can execute right next to the hardware and handle input events and draw interactive user interfaces locally without network traffic and context switching, and implement efficient application specific network protocols and rendering pipelines, just like NeWS?

Or, you know, like a web browser running an AJAX app like Google Maps? Certainly not Display PostScript, it can't do that, and nobody uses it any more for some reason or another.

>> Pie Menus

>Great for demos and to collect grant money, i guess. But in principle a total anti-pattern. People read from left to right and from top to bottom. Traditional context menus are therefore far superior, especially for varying numbers of options.

A lot more than grant money: The Sims has made EA $5 billion (as of 2019), putting pie menus into 70 million people's hands, and Blender and many other programs use them too. Have you ever played The Sims or used Blender?

https://fortune.com/2025/01/31/the-sims-25-anniversary/

What's your evidence for that claim that "Traditional context menus are therefore far superior"? Citations, or are you just bullshitting? Thanks to Fitts's Law, which every user interface designer should be familiar with, pie menus are much faster and have a significantly lower error rate than linear menus, so you're simply wrong about traditional menus being "far superior".

https://en.wikipedia.org/wiki/Fitts%27s_law

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

We empirically proved that and published our findings at ACM SIGCHI in 1988, and since then many other people have performed controlled experiments replicating and elaborating our frequently cited results.

https://donhopkins.medium.com/an-empirical-comparison-of-pie...

>> Weirdly dragable tabs

>Not impressed at all, sorry. Creates much more visual confusion than generic title bars.

Have you ever used a web browser? I'm guessing you are using one right now! You must be pretty easily confused, so speak for yourself, please don't project your confusion onto others, we're doing just fine being not confused. Is the confusion in the room with you right now? ;)

Maybe you can reduce your confusion by reading the wikipedia article about tabbed windows. That screen dump in the article is an illustration of UniPress Emacs with tabbed windows and the HyperTIES hypermedia browser with pie menus and interactive PostScript "applets" (long before that term was coined for Java applets, or the term "AJAX" was coined for JavaScript web apps), which I developed for NeWS in 1988 or so. No coincidentally, James Gosling developed UniPress Emacs, NeWS, and Java.

https://en.wikipedia.org/wiki/Tab_(interface)

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

DonHopkins on April 12, 2016 | parent | context | favorite | on: NeWS – Network Extensible Window System

NeWS was not actually Adobe's Display PostScript, but it was Sun's independent implementation and specialized dialect of PostScript, supporting light weight processes, overlapping arbitrarily shaped canvases, window management, event distribution, garbage collection, networking, object oriented programming, etc.

The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server.

That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting!

James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought.

To quote the comparison from the wikipedia article:

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

1) used PostScript code instead of JavaScript for programming.

2) used PostScript graphics instead of DHTML and CSS for rendering.

3) used PostScript data instead of XML and JSON for data representation.

Re: Ancient X11 scaling technology

#112

Post by lmm »

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

> You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it.

Skill issue. You probably held your keyboard wrong or something. Simple xrandr commands work fine like they have for decades. (Of course if you've moved to Wayland then who knows).

Re: Ancient X11 scaling technology

#113

Post by kergonath »

qarl wrote: post #77
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?

You're thinking of NeXTSTEP. Before OS X.

NeXTSTEP was Display PostScript. MacOS X uses Display PDF since way back in the developer previews.

Re: Ancient X11 scaling technology

#114

Post by kalleboo »

zozbot234 wrote: post #23
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…

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?

OS X could do it, they actually used to support enabling fractional rendering like this through a developer tool (Quartz Debug)

There were multiple problems making it actually look good though - ranging from making things line up properly at fractional sizes (e.g. a "1 point line" becomes blurry at 1.25 scale), and that most applications use bitmap images and not vector graphics for their icons (and this includes the graphic primitives Apple used for the "lickable" button throughout the OS.

edit: I actually have an iMac G4 here so I took some screenshots since I couldn't find any online. Here is MacOS X 10.4 natively rendering windows at fractional sizes: https://kalleboo.com/linked/os_x_fractional_scaling/

IIRC later versions of OS X than this actually had vector graphics for buttons/window controls

Re: Ancient X11 scaling technology

#115

Post by atq2119 »

sho_hn wrote: post #59
pedrocr wrote: post #47

Earlier quoted context omitted.

That's what I referred to with "we'll be finally getting that in Wayland now". For many years the Wayland protocol could only communicate integer scale factors to clients. If you asked for 1.5 what the compositors did was ask all the clients to render at 2x at a suitably fake size and then scale that to the final output resolution. That's still mostly the case in what's shipping right now I believe. And even in integ…

In KDE Plasma we've supported the way you like for quite some years, because Qt is a cross-platform toolkit that supported fractional on e.g. Windows already and we just went ahead and put the mechanisms in place to make use of that on Wayland. The standardized protocols are more recent (and of course we heavily argued for them). Regarding the way the protocol works and something having to be retrofitted, I think you…

Thank you for that. The excellent fractional scaling and multi-monitor support is why I finally switched back to KDE full time (after first switching away during the KDE 3 to 4 mess).

Re: Ancient X11 scaling technology

#116

Post by atq2119 »

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…

Not to mention that only a small fraction of the world uses inches...

Re: Ancient X11 scaling technology

#117

Post by kccqzy »

enriquto wrote: post #85
sho_hn wrote: post #42

Earlier quoted context omitted.

What you want is exactly how fractional scaling works (on Wayland) in KDE Plasma and other well-behaved Wayland software: The scale factor can be something quirky like your 1.785, and the GUI code will generally make sure that things nevertheless snap to the pixel grid to avoid blurry results, as close to the requested scaling as possible. No "extra window system transforms".

> The scale factor can be something quirky like your 1.785, and the GUI code will generally make sure that things nevertheless snap to the pixel grid to avoid blurry results This is horrifying! It implies that, for some scaling factors, the lines of text of your terminal will be of different height. Not that the alternative (pretend that characters can be placed at arbitrary sub-pixel positions) is any less horrifyin…

> The bitter truth is that fractional scaling is impossible.

That's overly prescriptive in terms of what users want. In my experience users who are used to macOS don't mind slightly blurred text. And users who are traditionalists and perhaps Windows users prefer crisper text at the expense of some height mismatches. It's all very subjective.

Re: Ancient X11 scaling technology

#118

Post by atq2119 »

astrange wrote: post #79
zozbot234 wrote: post #73

Earlier quoted context omitted.

> Free-scaling UIs were tried for years before that and never once got to acceptable quality. The web is a free-scaling UI, which scales "responsively" in a seamless way from feature phones with tiny pixelated displays to huge TV-sized ultra high-resolution screens. It's fine.

That's actually a different kind of scaling. The one at issue here is closer to cmd-plus/minus on desktop browsers, or two-finger zooming on phones. It's hard to make that look good unless you only have simple flat UIs like the one on this website. They did make another attempt at it for apps with Dynamic Type though.

I'm certain that web style scaling is what the vast majority of desktop users actually want from fractional desktop scaling.

Thinking that two finger zooming style scaling is the goal is probably the result of misguided design-centric thinking instead of user-centric thinking.

Re: Ancient X11 scaling technology

#119

Post by inetknght »

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

"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. Then there's all the security concerns that solidify that.

But yes, it does work reasonably well, and it is actually really cool. I just wish it were... better.

Re: Ancient X11 scaling technology

#120

Post by kllrnohj »

jdsully wrote: post #78
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…

Windows tried this for a long time and literally no app was able to make it work properly. I spent years of my life making Excel have a sane rendering model that worked on device independent pixels and all that, but its just really hard for people not to think in raw pixels.

And yet every Android app does it just fine :)

The real answer is just it's hard to bolt this on later, the UI toolkit needs to support it from the start

Post reply on HN