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

How X Window Managers Work, and How to Write One (2014)

jichu4n.com

Post reply on HN
Print view View original

161–170 of 250 posts

Re: How X Window Managers Work, and How to Write One (2014)

#161

Post by loxias »

kaba0 wrote: post #133
loxias wrote: post #128

Earlier quoted context omitted.

> a middleman in the communication of applications and the compositor There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of the…

> start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well. That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which ha…

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor.

Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.

I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.

I think we can put this "Xorg video playback has tearing" myth to bed.

It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)

> X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other.

I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!

I really really think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.

But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.

Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)

Re: How X Window Managers Work, and How to Write One (2014)

#162

Post by loxias »

md8z wrote: post #158
loxias wrote: post #128

Earlier quoted context omitted.

> a middleman in the communication of applications and the compositor There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of the…

"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy." Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

> ... "correctly" ...

You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.

I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.

Re: How X Window Managers Work, and How to Write One (2014)

#163

Post by md8z »

loxias wrote: post #162
md8z wrote: post #158

Earlier quoted context omitted.

"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy." Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

> ... "correctly" ... You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective . To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen. I will (grudgingly!) concede that perhaps it's not "universally and o…

We don't though, I mean if you explicitly change the scaling factor. Of course if you don't change the scaling factor then your scaling would technically be correct.

Re: How X Window Managers Work, and How to Write One (2014)

#164

Post by yjftsjthsd-h »

DonHopkins wrote: post #140
vidarh wrote: post #103

Earlier quoted context omitted.

> Mid 80s hardware, actually. I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :) > WHAT IS YOUR ROOT? A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though. The X protocol is messy in places, but Xlib is far worse than nec…

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib. I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp. https://www.cliki.net/clx Few people still write applications directly to XLib, but many do write ap…

> That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries

Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.

Re: How X Window Managers Work, and How to Write One (2014)

#165

Post by md8z »

loxias wrote: post #161
kaba0 wrote: post #133

Earlier quoted context omitted.

> start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well. That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which ha…

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor. Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a…

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame sync).

Re: How X Window Managers Work, and How to Write One (2014)

#166

Post by yjftsjthsd-h »

Hendrikto wrote: post #77
loxias wrote: post #24

Earlier quoted context omitted.

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were. Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

> And I am sure, if you really think about it, you know this yourself.

I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.

Re: How X Window Managers Work, and How to Write One (2014)

#167

Post by md8z »

vidarh wrote: post #95
Seirdy wrote: post #70

Earlier quoted context omitted.

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. The difference will widen as Vulkan support in Wayland compositors seems to be outp…

X ran just fine on machines with graphics chips with no acceleration at all , just dumb frame buffers. You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance chara…

X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events...

Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.

Re: How X Window Managers Work, and How to Write One (2014)

#168

Post by kaba0 »

md8z wrote: post #165
loxias wrote: post #161

Earlier quoted context omitted.

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor. Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a…

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame syn…

It’s more like the video card: doing vsyncing, especially on video.

Re: How X Window Managers Work, and How to Write One (2014)

#169

Post by vidarh »

DonHopkins wrote: post #140
vidarh wrote: post #103

Earlier quoted context omitted.

> Mid 80s hardware, actually. I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :) > WHAT IS YOUR ROOT? A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though. The X protocol is messy in places, but Xlib is far worse than nec…

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib. I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp. https://www.cliki.net/clx Few people still write applications directly to XLib, but many do write ap…

Absolutely agree that a general purpose replacement for Xlib would be a massive pain, but providing sufficient support for the core protocol to let you add whichever request types you need is quite simple (and I lifted that from a decade old starting point and made it work).

And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.

But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.

Re: How X Window Managers Work, and How to Write One (2014)

#170

Post by md8z »

kaba0 wrote: post #168
md8z wrote: post #165

Earlier quoted context omitted.

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame syn…

It’s more like the video card: doing vsyncing, especially on video.

I don't understand, a video card cannot "do vsync" like that. If the program sends its contents at the wrong time then the video card can't do anything about that, the correct information is simply not there.
Post reply on HN