🍩 Doughnut Reader 🍩

This is why the XRender extension was introduced. There you have antialiasing, all blending modes you could wish for, subpixel coordinates, advanced drawing operations like gradients and it is fast because it is fully hardware accelerated. All working over a very efficient wire protocol. E.g. Cairo uses Xrender as a backend.

Nothing on your feature list is incompatible with a client/server approach though. The only downside would be when large data blobs need to be sent over a network each frame.

In the end, modern 3D APIs are also just a 'wire protocol': rendering commands are recorded by the CPU into local command buffers and played back by the GPU (which is often connected to the CPU by a comparatively slow bus), the only limiting factor is the amount of data that's communicated between the CPU and GPU - and of course any additional latency that would be added by a network connection.

I wonder if there could be a X server implementation that ran fully on the GPU.

It's like I say, Wayland is the replacement for X, but browsers and Electron are the replacement for NeWS.

VNC is also much faster in most cases, because the X protocol requires a lot of round trips that waste a lot of time. So instead the VNC server "runs these round-trips locally" (so to speak) and you only interact with the pixels remotely. X was developed when bandwidth was as limiting as latency but nowadays only latency is limiting so a different protocol makes more sense.

You can use Xpra, it's like tmux but for X. You can have your window follow you across clients.

Same deal with a remote shell. Usually it's not a problem, but if you anticipate it will be, you can use additional tools (screen, tmux, Xpra).

Xvnc is fine if you want a desktop session, but usually I just want one program, so X11 is a better fit for me. Once you have the infrastructure setup, it's really easy to go from a normal shell to running a graphical program. For me, I use a Microsoft Windows desktop environment, have X11 forwarding enabled on my usual shell targets, so I just start the X server and run the program. I could have the X server autostart (it's unobtrusive if there's no clients), but I haven't yet. On a mac, the Xserver starts automagically (once installed), so it's just a matter of enabling X forwarding in your ssh config to hosts where it's likely. Even less work if you run an X desktop.

> your windows will go away and your program will usually exit.

This is a huge improvement over most "web applications", whereby your client (web browser) sits there looking like it's doing something when your network connection goes away. Worse still, you don't know whether the last (trans)action you sent to the server was processed or not.

> This is fun and all, but if you lose your connection, your windows will go away and your program will usually exit.

Interestingly, that is xlib's behavior moreso than inherent in the protocol. xlib assumes connection lost is a fatal event, but if you're doing your own socket, you can choose to do this differently. (or, even with xlib, you can throw an exception from the connection lost callback and regain control before letting it abort)

Some server state is lost, but it is possible, with some care, to recreate that from your client upon reconnecting. You can even connect to a different server and somewhat seamlessly migrate windows over.

But yeah it isn't commonly done.

You can use xpra: https://xpra.org/index.html

This also works for running a Linux GUI on your phone in Termux. Termux+localhost VNC is the way for this.

xpra or x2go (can't remember) supported that.

> I don't think anyone ever made a text terminal with built-in telnet and ethernet.

Maybe not, but there were terminal servers with 10 serials ports for the glass terminals and an Ethernet connector.

Not telnet/ethernet, but later VTs had built-in modem controls and some utilities in firmware, so you could have an AT-capable modem connected over serial port and just select what connection to dial into.

It's already here, for more than a year, both on Windows 10 and 11. I use this for emacs (with a GTK build) every day.

WSL has been able to open graphical Linux apps for a while. They use Wayland (with FreeRDP to the Windows Host) and XWayland for X11 apps.

https://devblogs.microsoft.com/commandline/wslg-architecture...

I used to run everything over 100Mbps ethernet. It worked just fine. Two biggest issues: Ssh without tuning settings, and modern X applications increasingly doing client-side rendering into bitmaps and so being far more bandwidth hungry and not tested over the network. If it's the latter, VNC or XPRA are much better suited if what the app ends up doing is streaming bitmaps anyway, as they're actually optimised for that.

It’s usually SSH that’s the bottleneck though. If you just expose your local X11 TCP server port and connect to it from the server (X11 client) by setting the DISPLAY env properly, it will be much more responsive. Often indistinguishable from local apps. Secure the port with Wireguard, if you want to be a bit more responsible and still have good performance. Checked with Firefox, which works like a charm this way, but is unusable over SSH.

> can you imagine a browser this way?

It in fact works perfectly fine.

The catch is latency. In my case both hosts are on the same colo.

I remember, 20+ years ago running quake3 over remote X to my roommate machine and I was surprised that glx actually worked over the network with no issues.

It depends on how the client was written. If you build around asynchronous operations, you can get good throughput, and if you always stop and wait for a reply, you'll get bad throughput. If you buffer your output and don't actually send it for a while, that can also make the experience poor. Xlib pushed you in both those directions, but you can make terrible clients with any library.

My personal experience with Oracle products has always involved terrible UX, so I'm not surprised they built a terrible X client.

I've run browsers over X, sometimes actually remotely, and it's OK, but not great. I wouldn't recommend it for video, audio is out of scope, and start up can be very slow sometimes. It's something that used to work better, IMHO. Sometimes you need to try a couple browsers and see which one works better. As a sibling notes, it all feels untested, and I'm sure if developers were testing, they'd fix some of the things that are easier to fix.

X over SSH works really well for me as long as I enable SSH compression. At least for my usage, I can't tell it apart from a native window but then again I'm not running sophisticated programs which update frequently.

x2go is a bit smarter than pure x-forwardning and also allows you to resume a session at a different time (or on a different machine) similar to something like tmux. Much much better performance and does pretty well even on cellular.

A bit rough around the edges but brilliant for some usecases.

The use case was a whole bunch of cheap display server machines in a computer lab at a university with a very powerful machine running the computation-expensive client programs. You didn't need SSH for that and the only real problem was contention on the token ring (ah, the old days...)

I remember seeing this on HN a few months ago! Looks pretty badass. I plan to play around with it when I get some time. I love Ruby, and have long loved the idea of a WM/desktop in Ruby. A friend of mine is diehard Xmonad user and the power of being able to write code to extend the WM is fascinating.

Also just wanted to let you know that I sent you an email. Don't feel obligated to respond or anything, just wanted to let you know because I sometimes get emails from people on HN but they go to an inbox I don't often check so I often don't see them until long after unless they tell me in a comment that they emailed me.

I’d love to check out your Ruby code. Link?

I did some work on a MTA a while back and it was genuinely pretty neat to send legit emails to my real mail accounts by just connecting to a port and typing the raw SMTP commands into it. E.g. https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...

Simpler times, when we thought we could trust everyone on the net :)

When I first started using UNIX (Ultrix on a DECStation), I was floored by the wizardry of "hackers" sending me email from Santa Claus. Mind blown!

Usenet gives full help over telnet, it's nice.

I think principally, it's not actually that much worse. However, there are some aspects of Wayland that are much better and much worse for people who prefer to go their own way.

With Wayland, the protocols are specified in machine-readable XML files, not unlike how XCB works, and typically a program called a "scanner" would read those XML files and perform code generation. So if you wanted to generate proper Wayland bindings, you'd need to write the scanner. The scanner is not terribly complicated. I did it in Go with around 750 SLOC, not counting the supporting code. It's not released, but here's just the code generation part, if you are curious. Last I used it, it could generate all of the Wayland protocols, and I was successfully using dozens of them from my own Go bindings.

https://gist.github.com/jchv/adcb6de1c9dc3d0112dea704d753803...

Of course, if you just want to implement Hello World, you don't need to use code generation, and the resulting amount of work to interface with X11 is ultimately similar to that of Wayland. But there are two huge caveats:

- Right now, the EGL interface for Wayland requires that you pass libwayland wl_surface structures. That means to get on-screen hardware accelerated contexts in Wayland, you have to link to libwayland (maybe making compatible structures would work if you're into that kind of thing, but definitely no easy options.)

- X11 has many server-side features that Wayland doesn't. Wayland's core protocols don't specify even window decorations or cursor shape, so a Wayland client has to implement drawing window decorations and loading cursor themes to properly support all Wayland compositors... even if they would prefer to use xdg-decoration and cursor-shape-v1. This is on top of things that no Wayland compositor has support for, like an equivalent to XRender or indirect rendering with OpenGL; those things just don't exist.

So it's far from perfect. Though, it's also not like X11 was free of cruft or design issues, either. I'm pretty sure with X you also have to implement cursor themes yourself, by virtue of linking to XCURSOR. And while you can use XRender and other server side rendering features, which will be way more efficient for remote usage than simply opening a GL or Vulkan context, most software (GTK, Electron) doesn't do this anymore, and either ships buffers over shared memory or opens a direct hardware accelerated context.

Personally, the problem I'd really like to see fixed is the EGL ABI one, but I'm pretty disillusioned by the bullshit in anything RedHat indirectly touches (e.g. Freedesktop.org), so even if there's a chance I could help, at this point, I'd rather spend my time working on other things.

I think Wayland works similarly, in a sense that you open a Unix domain socket and send and receive bytes, see https://wayland.freedesktop.org/docs/html/ch04.html.

But I'm pretty sure it's more complicated than I think. :-)

Somewhat misleading. Because these days, none of the network transparent primitives are used anymore. All the rendering happens server side, and bitmaps are sent over the wire. It's basically a crappy VNC. And at that point, just use RDP or VNC

AFAIK, Windows Remote Desktop always renders through virtual display adapter devices, though it can optionally make use of GPU resources to accelerate rendering to these devices.

I just tested in an ESXi VM[1], and Windows 10 will happily boot and accept an RDP connection without any (virtual) display hardware at all:

https://jasomill.at/HeadlessRDP.png

Whether a particular computer will boot Windows without display hardware depends on the firmware — in my experience, some workstations will, some won't, and I honestly haven't seen a modern x86 server without some sort of integrated graphics to support out-of-band management, often with a VGA port as the only physical video output.

[1] By hand-editing the VM's .vmx configuration file, setting

  svga.present = "FALSE"

  hwm.svga.notAlwaysPresent = "TRUE"

https://jasomill.at/vmx.ss.html#L-808

In fact, two definitions and a couple trivial syntax fixes are enough to get Chez Scheme to evaluate it without warnings:

  $ awk -f - vmx.ss <<EOF | scheme -q
    BEGIN {
        print "(define / fxdiv)"
        print "(define (log . args) (for-each display args))"
    }
    {
        gsub(/\(\)/, "'()")
        gsub(/ 0x/, " #x")
        print
    }  
  EOF
  $

Yeah on macos the communication between your app and the window server (which is conveniently called WindowServer) happens via mach ports. Most of it is undocumented, in fact anything more "low-level" than using AppKit is undocumented, although IIRC it is in principle possible to use undocumented CG* apis to create and manipulate windows yourself without going through the appkit layers. I think each CG* api is basically a thin shim that communicates to the window server, which has a corresponding CGX* implementation which does the actual logic. This article has some details https://keenlab.tencent.com/en/2016/07/22/WindowServer-The-p...

I might be wrong but I think the closest thing in windows land is RDP with regard to low level rendering of the display over the network

You got any source for this? I am only asking since I got the impression rdp was a superior protocol to vnc, nx etc because of the complex handling of graphical primitives. But I know next to nothing about the real technical details.

That's why where is __attribute__((packed))

> There is no portable way to define structure alignment and padding in C

Of course there is __attribute__((packed)) and __attribute__((aligned(8)))

While under-researched statements aren't good, personal attacks don't help either. Prefer to educate instead.

C structs have packing, alignment, and endianness gotchas that can be portably addressed with byte-level de/ser.

Example: https://gist.github.com/cd089675a6088b0b8482c005a0e3897a