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

91–100 of 134 posts

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

#91

Post by josteink »

hota_mazi wrote: post #80

What's fascinating to me is that X11 and Windows started at complete opposite ends of the spectrum. Then X11 never managed to be a really effective window manager on a local workstation while Windows became really, really good at remote displays.

That can be explained by economics alone.

There were no financial driver to make X11 a more optimal local solution.

There were huge financial incentives for MS to make their terminal-server offering more appealing.

And that’s all you need to explain the outcome.

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

#92

Post by pcwalton »

Jasper_ wrote: post #84
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 have a lot of replies to this, but the back-and-forth format that HN has isn't the best for collaborative discussion. Imagine us sitting in a room with a whiteboard, rather than bickering at each other at loud volume. If you're ever in south bay area and want to meet up at a coffee shop, let's :) > Basically, my question is whether anybody is working on a solution for the hardware we have today, where there are har…

> If you're ever in south bay area and want to meet up at a coffee shop, let's :)

For what it's worth, I would be very interested in chatting about this too, as this is my area right now. I'm working on what will hopefully become the Firefox OS compositor integration library, with an eye toward optimum power consumption, and am knee-deep in details of cross-platform composition. It's a very interesting topic.

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

#93

Post by pcwalton »

sprash wrote: post #19

Money Quote: > So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice. That is something that can not be said about Wayland. Besides the "every frame is perfect"…

As someone who is working with X11, I strongly disagree. It really needs replacing badly. It doesn't even work; only a few code paths even get tested on for example GLX, which is why complex X11 apps like browsers need blacklists.

> There is a reason why Intel still stuffs the i368 instruction set in their processors

If you want a CPU analogy, Wayland is more like ARMv8, which was mostly a clean break in terms of the AArch64 ISA, but which still supports 32-bit at the process level. 32-bit and 64-bit code cannot be intermixed in the same address space, but you can run 32-bit and 64-bit apps simultaneously on the same OS, analogously to the way you can run X11 and Wayland apps on the same Wayland desktop using Xwayland. This actually worked out beautifully, and I would have preferred that x86 had followed the same trajectory.

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

#94

Post by Mathnerd314 »

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…

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-screen mode. Monitor, graphics card, and game engine developers are all doing interesting things with scheduling there, but the main function of the OS / compositor is to get out of the way.

Beyond that there's video playback, but 60fps video is rare, videos have (relatively) huge buffers of decoded video, and dropped frames are easy to overlook, so I don't think it's much of a priority for the OS. Nobody will notice the window manager adding an extra 10ms delay to the video.

Businesses don't care about visual fidelity at all, the most common monitor size is still 1366 x 768. So there's no big push commercially, besides the aforementioned VR/AR.

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

#95

Post by iforgotpassword »

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…

Hey, that YouTube video got recommended to me a couple days ago on their front page and I really enjoyed watching it. One of the few instances where YouTube didn't recommend random crap or just videos of channels I'm already following.

Again, great job! That's exactly the kind of content I'm enjoying most on YouTube.

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

#96

Post by imglorp »

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&page=0&prefix=false&qu...

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

#97

Post by asveikau »

hota_mazi wrote: post #80

What's fascinating to me is that X11 and Windows started at complete opposite ends of the spectrum. Then X11 never managed to be a really effective window manager on a local workstation while Windows became really, really good at remote displays.

I feel like this is short changing X. I have seen it as a good local solution over 20 years or so.

Did you ever see those 90s commercial Unix workstations? Like from SGI?

How about a Nokia N900? X on a smartphone. It ran pretty well. Today's smartphone hardware would run circles around that thing so I can only assume if somebody ported X to those it would also do fine.

I feel like people see things they don't like or imperfections and bash the whole thing as useless. X had a lot of mileage. I use it frequently today and don't see a lot of problems.

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

#98

Post by gmueckl »

shmerl wrote: post #87
gmueckl wrote: post #75

Earlier quoted context omitted.

In what world are nVidia drivers crap? I'm regularly doing some pretty funky stuff with OpenGL on top of X11 and nVidia and this setup fails me less often and less hard than any equivalent AMD setup has done so far. Unless I'm trying to allocating tons textures or ridiculously sized vertex buffers, I don't see any hickups at all.

In the Linux world. All of their problems (roughly you can call them poor integration with the Linux stack) are consequences of them refusing to upstream their kernel driver. The fact that Nvidia blob fails you less is not a good indicator for you, unless you test with Mesa as well in each case. Mesa is a lot stricter about OpenGL spec compliance. So if you only test on Nvidia, you likely have bugs that you didn't no…

Every time I tested with Mesa and had issues, it turned out that Mesa was out of spec and quite specifically lying about that fact. And this was with absolutely essential features like rendering into floating point textures. So no, Mesa is not an indicator for spec compliance, either.

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

#99

Post by vrodic »

pcwalton wrote: post #93
sprash wrote: post #19

Money Quote: > So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice. That is something that can not be said about Wayland. Besides the "every frame is perfect"…

As someone who is working with X11, I strongly disagree. It really needs replacing badly. It doesn't even work ; only a few code paths even get tested on for example GLX, which is why complex X11 apps like browsers need blacklists. > There is a reason why Intel still stuffs the i368 instruction set in their processors If you want a CPU analogy, Wayland is more like ARMv8, which was mostly a clean break in terms of th…

> As someone who is working with X11, I strongly disagree. It really needs replacing badly. It doesn't even work; only a few code paths even get tested on for example GLX, which is why complex X11 apps like browsers need blacklists.

Blacklists are needed because OpenGL drivers for specific hardware have bugs and can have missing functionality. Those can affect Wayland too, since the same drivers are used.

Modern Xorg supports direct rendering well, Keith Packard authored a lot of modernized infrastructure such as DRI2/DRI3, and even support for VR (work he's been doing for Valve).

There's also the important VK_display_timing extension implementation he's done with Croateams Alen Ladavac:

https://twvideo01.ubm-us.net/o1/vault/gdc2018/presentations/... on Xorg

Sadly, I don't see much more recent activity from him or Alen about these topics, but it shows that Xorg is still the main platform of inovation for Linux real-time graphics needs.

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

#100

Post by zaxcellent »

pcwalton wrote: post #92
Jasper_ wrote: post #84

Earlier quoted context omitted.

I have a lot of replies to this, but the back-and-forth format that HN has isn't the best for collaborative discussion. Imagine us sitting in a room with a whiteboard, rather than bickering at each other at loud volume. If you're ever in south bay area and want to meet up at a coffee shop, let's :) > Basically, my question is whether anybody is working on a solution for the hardware we have today, where there are har…

> If you're ever in south bay area and want to meet up at a coffee shop, let's :) For what it's worth, I would be very interested in chatting about this too, as this is my area right now. I'm working on what will hopefully become the Firefox OS compositor integration library, with an eye toward optimum power consumption, and am knee-deep in details of cross-platform composition. It's a very interesting topic.

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.
Post reply on HN