Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the working of X11 from the ground up (2017)

magcius.github.io

Post reply on HN
Print view View original

111–120 of 134 posts

Re: Understanding the working of X11 from the ground up (2017)

#111

Post by Mathnerd314 »

rasz wrote: post #101
Mathnerd314 wrote: post #94

Earlier quoted context omitted.

Wayland's latency was improved a few years ago to about half a frame, there's probably more room for improvement, but I think just getting a 240hz monitor is better investment of resources: https://ppaalanen.blogspot.com/2015/02/weston-repaint-schedu... The only applications strongly sensitive to latency are video games or similar, and they take a special low-latency path through the graphics stack, exclusive full-sc…

>The only applications strongly sensitive to latency are video games paining with a pen/tablet/mouse

You can still paint with 200ms of latency, it just isn't very pleasant. Atom adds an average of 50ms of latency, people still use it: https://pavelfatin.com/typing-with-pleasure/.

As far as pointing devices, people are apparently habituated to the 50ms response time, and massaging of the lower-latency data only showed effects above 16ms: https://wp.cs.ucl.ac.uk/sebastianfriston/wp-content/uploads/...

I think artists are more interested in pen/display combinations though. There's a study of touch dragging, where the average is somewhere around 6ms: https://www.tactuallabs.com/papers/designingLowLatencyDirect...

It still seems like it's mostly about having the bandwidth to drive a 240hz or higher display though. The ongoing computation required for painting is minimal. Unless Wayland or X are doing a lot of IPC on every frame there's no reason to write a new graphics stack.

Re: Understanding the working of X11 from the ground up (2017)

#112

Post by bscphil »

Jasper_ wrote: post #73

Author here. I stopped working on this a few years ago, so now's as good a time as any for an overly-long, rambly, unedited retrospective. When I started this, I was working on GNOME's window manager full-time, and wanted to learn intricately how X11's drawing model worked, so over the course of a few weeks in a hotel room, I recreated large parts of X11's drawing model in a web browser, fixing artifacts as I went al…

The examples in this link don't work for me in the latest Firefox or Chromium (or Brave) on Linux. https://blog.mecheye.net/2018/03/deconstructing-the-water-ef...

Edit: neither does anything here: https://noclip.website/

Re: Understanding the working of X11 from the ground up (2017)

#113

Post by 0xdeadb00f »

sverige wrote: post #60
krychu wrote: post #58

I haven't used linux as my primary OS for many years now. If not X11 or Wayland, what other alternative? Is there some other relevant development going on?

OpenBSD is still actively developing xenocara, which is their fork of X11.

That still counts as "X11" IMO.

Re: Understanding the working of X11 from the ground up (2017)

#114

Post by majewsky »

djsumdog wrote: post #90
majewsky wrote: post #36

Earlier quoted context omitted.

> I respect the intention and efforts of the Wayland community to make things better. My understanding is that Wayland was started by a few core developers of Xorg who just couldn't stand maintaining Xorg anymore.

It is, including the author of this post. Unlike other controversial things like systemd or pulseaudio, Wayland was started by major Xorg contributors. I've watched some of their talks and can see why they went down this route. I've tired Wayland a few times and whenever I do, I give it an honest shot for a few weeks, but tend to run into issues (Sway being pretty buggy or oddities with old X apps or Steam, etc.) I'v…

I used Sway during the 0.14 cycle and ran into some issues e.g. with pointer warping in X-based games, so I decided to wait until 1.x. I just switched to Sway again, with 1.1.2 AFAIR, and mostly everything is working smoothly for me this time around, including Minecraft. :)

Things that don't work for me:

- mirroring (i.e. two displays showing the same windows at once), but AFAIK this is being worked on

- KDE Connect (not Sway's fault, but not having this working really hurts sometimes and might just make me go back to Plasma)

Re: Understanding the working of X11 from the ground up (2017)

#115

Post by Jasper_ »

bscphil wrote: post #112
Jasper_ wrote: post #73

Author here. I stopped working on this a few years ago, so now's as good a time as any for an overly-long, rambly, unedited retrospective. When I started this, I was working on GNOME's window manager full-time, and wanted to learn intricately how X11's drawing model worked, so over the course of a few weeks in a hotel room, I recreated large parts of X11's drawing model in a web browser, fixing artifacts as I went al…

The examples in this link don't work for me in the latest Firefox or Chromium (or Brave) on Linux. https://blog.mecheye.net/2018/03/deconstructing-the-water-ef... Edit: neither does anything here: https://noclip.website/

Blame your graphics drivers. The lack of working modern graphics on Linux is one of the reasons I moved away from it. It works fine for me locally, so it's an issue with your machine. Stare at chrome://gpu and https://webglreport.com/?v=2 for a bit, or maybe file a bug with your graphics driver.

Re: Understanding the working of X11 from the ground up (2017)

#116

Post by vetinari »

bscphil wrote: post #112
Jasper_ wrote: post #73

Author here. I stopped working on this a few years ago, so now's as good a time as any for an overly-long, rambly, unedited retrospective. When I started this, I was working on GNOME's window manager full-time, and wanted to learn intricately how X11's drawing model worked, so over the course of a few weeks in a hotel room, I recreated large parts of X11's drawing model in a web browser, fixing artifacts as I went al…

The examples in this link don't work for me in the latest Firefox or Chromium (or Brave) on Linux. https://blog.mecheye.net/2018/03/deconstructing-the-water-ef... Edit: neither does anything here: https://noclip.website/

It doesn't work in Firefox for Mac either.

It does in Chrome.

Re: Understanding the working of X11 from the ground up (2017)

#117

Post by pcwalton »

raphlinus wrote: post #105
zaxcellent wrote: post #100

Earlier quoted context omitted.

This topic is also of interest to me. I work on a compositor integration protocol called virtio-wayland that is intended to allow Wayland apps running inside of VMs to communicate with a Wayland compositor on the host, shared memory and all. It's used for the Linux apps support for Chrome OS.

I don't get to the south bay often, but sounds like it might be good to have a little compositor meetup. I can certainly vouch for pcwalton's interest and knowledge in the topic :) Follow up by email?

Sounds good to me!

Re: Understanding the working of X11 from the ground up (2017)

#118

Post by kragen »

raphlinus wrote: post #82

Looking over this stuff, I get an uneasy feeling. X was a brilliant solution to problems 35 years ago, where you barely had enough memory for a full frame buffer and the graphics model was primitive (no antialiasing or transparency). From what I've seen, Wayland is a good solution for the model maybe 15 years ago, where you're willing to accept the frame-and-a-half latency hit from having a compositor in the path. Ba…

I agree, and I've written a bunch of stuff in Dercuano about this problem, notes/real-time-windowing.html and notes/wercam-scriptable-windows.html for example. I'm interested to hear what approaches you think are likely to help with the problem.

The current version of Dercuano, in the unlikely chance that you want to read my incomplete and unedited notebook, is in http://canonical.org/~kragen/dercuano-20190915.tar.gz.

Re: Understanding the working of X11 from the ground up (2017)

#119

Post by kragen »

imglorp wrote: post #96
raphlinus wrote: post #82

Looking over this stuff, I get an uneasy feeling. X was a brilliant solution to problems 35 years ago, where you barely had enough memory for a full frame buffer and the graphics model was primitive (no antialiasing or transparency). From what I've seen, Wayland is a good solution for the model maybe 15 years ago, where you're willing to accept the frame-and-a-half latency hit from having a compositor in the path. Ba…

I would like to see someone reimplement NeWS now. Hardware is way faster and we have more choices of embedded interpreter. Not that PostScript was, and is, not genius for that purpose, but there choices. Also, Don Hopkins hangs out on HN, where he's already weighed in a few times with some ideas for future work if you grok through his comments. https://en.wikipedia.org/wiki/NeWS https://hn.algolia.com/?dateRange=all&…

On the contrary, PostScript was a brilliant choice for scripting your window system at the time (≈1990). The modern crop of dynamic languages hadn't matured (JS, Guile, Python, Perl, Ruby, even Tcl), so the only real alternative would have been a Lisp, and PostScript already had a truly great graphics API — an improvement in many ways over many of its successors, including X11 and Windows GDI. Gosling certainly could have implemented something like Emacs Lisp, and it would have been easier to program in than PostScript, but it also would have been painfully slow, and he would have had to do the graphics API design work — and probably fucked it up, as the Win16 and X11 teams did. Even today, PostScript interpreters are quite a bit faster than most of the language implementations I described above, though modern JS, LuaJIT, Self, and of course HotSpot Java do beat them.

Re: Understanding the working of X11 from the ground up (2017)

#120

Post by kragen »

zzzcpan wrote: post #71
alxlaz wrote: post #66

Earlier quoted context omitted.

Yeah, I also should have said that the response of the other part of the community isn't exactly sympathetic (or useful), either. Truth is, a lot of the reason why X11 works so well today is that a bunch of us put up with a lot of X11 crap back in the day. E.g. things like xdotool haven't existed forever, either, and it took a lot of itches (and imperfect way of scratching them) before someone wrote that. X11 wasn't…

> And all this is in a context were fewer and fewer developers are interested in desktop development, and fewer and fewer companies are interested in investing in desktop development. Which could make X11 the last linux/unix desktop thing. Anything new would have to come with the whole desktop paradigm shift.

SurfaceFlinger.
Post reply on HN