Most active commenters
  • ianburrell(3)

←back to thread

The X Window System didn't immediately have X terminals

(utcc.utoronto.ca)
110 points zdw | 11 comments | 23 Jun 25 03:50 UTC | HN request time: 1.515s | source | bottom
Show context
ggm ◴[23 Jun 25 07:38 UTC] No.44353361[source]▶
I had to both administer, and operate on the early X terminals from several vendors they were interesting. Labtam made strides developing boxes using the more novel Intel chips and this may have been what they sold on when they got out of the business and moved to being an ISP in Australia.

I enjoyed using blits and the early dec Ultrix workstations.

Thin X terminals were super cool. But, also really stressed out your Ethernet, and because we didn't have good audio models in X at that time, when multimedia became viable they stopped being as useful. But for a distraction free multiple term, low overhead wm world... super good price performance cost.

replies(1): >>44353546 #
wkat4242 ◴[23 Jun 25 08:18 UTC] No.44353546[source]▶
I was surprised how a room of top notch 1280x1024 terminals was able to function so well on a shared 10mbps with pretty bad collision detection to boot. X apps of the day were super optimised for local drawing. Even games were super smooth. Toolkits like Motif were all draw calls. By the way back then we thought Motif was bloated lol :)

And then... Came the internet. People suddenly started running NCSA Mosaic in droves that bogged down the single core server. And those browsers started to push lots of bitmap stuff through the pipe to the terminals. Now that was bad, yes. When Netscape came with its image backgrounds and even heavier process people started moving away to the PC rooms :( Because all scroll content needed to be bitstreamed then.

Ps video content at that time wasn't even a thing yet. That came a bit later with realvideo first.

But there was a time when X terminals were more than sufficient, probably for a decade or so.

replies(2): >>44353911 #>>44354037 #
1. bmacho ◴[23 Jun 25 09:40 UTC] No.44353911[source]▶
> Because all scroll content needed to be bitstreamed then.

Is it better now? Can a browser locally scroll an image, without restreaming it?

replies(4): >>44354762 #>>44357783 #>>44358379 #>>44359070 #
2. londons_explore ◴[23 Jun 25 11:47 UTC] No.44354762[source]▶
A modern browser (ie. chromium) uses the GPU for all drawing.

Here is an awesome (slightly outdated) talk about the architecture: https://groups.google.com/a/chromium.org/g/blink-dev/c/AK_rw...

The basic idea is that HTML content is drawn in transparent 'tiles' which are layered on top of one another. When the user scrolls, the tiles don't need to be redrawn, but instead just re-composited at their new positions. GPU's are super fast at that, and even a 15 year old GPU can easily do this for tens of layers at 60 FPS.

On a linux with a remote X server, I think the tiles would all end up on the X server, with only the pretty small 'draw tile number 22 at this location' going across the network. So the answer to your question is 'yes'.

replies(1): >>44356972 #
3. lxgr ◴[23 Jun 25 15:48 UTC] No.44356972[source]▶
Does all of that (i.e. GPU rasterization and GPU compositing) really work over the network with common browsers?

Based on my limited experience, the performance of running Firefox remotely on a local X11 server was very poor, and I assumed that the absence of these types of acceleration were to blame.

I could imagine XRender to work, though, which would at least support blitting most of the pixels up/down in case of scrolling, and would only require pushing new ones over the network for any newly exposed areas.

replies(1): >>44357600 #
4. londons_explore ◴[23 Jun 25 16:44 UTC] No.44357600{3}[source]▶
A quick test shows that chromium at least cannot use the GPU with a remote X connection. Loading the google homepage is ~100 megabytes of data across the X connection, and scrolling up and down for a few seconds sends a further 1 gigabyte.

My guess is the lack of shared memory buffers stops the use of opengl, and whilst it's theoretically possible, it is probably unimplemented because nobody does that in 2025.

replies(2): >>44358391 #>>44358911 #
5. aidenn0 ◴[23 Jun 25 17:05 UTC] No.44357783[source]▶
It's much worse. Now fonts are rendered in the client then streamed over the network to the server as bitmaps.
replies(1): >>44358347 #
6. ianburrell ◴[23 Jun 25 17:57 UTC] No.44358347[source]▶
XRender extension can load font glyphs into the X server and do the rendering locally. But that requires the browser, the X client, to know about this and not do rendering itself.
7. ianburrell ◴[23 Jun 25 18:01 UTC] No.44358379[source]▶
I think the XRender extension allows scrolling images. XRender allows quick recompositing of text and images.

But this requires the browser have a special path for remote X and not just use the GPU. Or even just a path for X that lets the X Server do the rendering.

8. ianburrell ◴[23 Jun 25 18:02 UTC] No.44358391{4}[source]▶
GLX used to work with remote X, what is called indirect rendering, but it sounds like it stopped working recently. Maybe doesn't support recent OpenGL, or nobody uses it so nobody maintains it.
replies(2): >>44358898 #>>44363464 #
9. rbanffy ◴[23 Jun 25 18:58 UTC] No.44358898{5}[source]▶
Could as well be that everyone forgot it existed.
10. jandrese ◴[23 Jun 25 19:16 UTC] No.44359070[source]▶
In theory you can send the images over as X backing stores and do just that. But I'm not sure it was implemented that way.

I remember GTK 1 was well optimized for X and you could run GTK applications over slow modem lines quite comfortably. GTK 2 went a different direction entirely and became almost unusable over the Internet. I doubt GTK 3 or 4 are any better now that they're designed for compositors.

11. toast0 ◴[24 Jun 25 06:46 UTC] No.44363464{5}[source]▶
I don't think this has worked well in quite some time. Maybe not ever in open source land.

IMHO, widespread use of Xlib lead people to believe that X was much more synchronous than it is, and discouraged people from using networking, and then a lot of stuff that could be possible didn't get made. xcb is a much better way to interact with X, but it may have arrived too late.