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

211–220 of 250 posts

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

#211

Post by destructionator »

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...

> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).

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

#212

Post by destructionator »

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…

> X is still fundamentally an unsychronized protocol

Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands.

I've also never seen tearing in X since like 2006.

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

#213

Post by kaba0 »

destructionator wrote: post #210
kaba0 wrote: post #93

Earlier quoted context omitted.

Or just try to go at things with an open-mind and hell, you might learn something? X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayla…

This post is completely false. Literally every word of it is false.

GPUs don’t have a single start, at least it depends on how you define them, but arguibly the first generally available one came in the late 1990s, compared to the various X server implementations that were around before that as well.

About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)

Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.

And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?

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

#214

Post by vidarh »

md8z wrote: post #194
vidarh wrote: post #190

Earlier quoted context omitted.

Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure. Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help y…

Once you are talking about double/triple buffering every client, you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue. Of course Wayland doesn't "solve" it but it does remove the old slow code paths. If you're on an SoC with a GPU then you want to use it as much as you can otherwise you are wasting CPU. The rest of your comment doesn'…

> Once you are talking about double/triple buffering every client

Nobody is talking about double/triple buffering every client, but the final composited surface.

> you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue

Double-buffering was viable and done on quite a lot of 1980's hardware. The point remains that this is not a protocol issue.

> Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not.

I didn't suggest it would have been simple. I suggested it would have been simple than a well over decade long effort to write a new system from scratch.

The point being that the reasons for the existence of Wayland are not technical, but political, due to the lack of willingness in the Xorg core team to break compatibility at the time. And we're still paying the price.

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

#215

Post by vidarh »

md8z wrote: post #192
vidarh wrote: post #191

Earlier quoted context omitted.

And I see no purpose in switching to Wayland as long as Xorg keeps working just fine. > If you liked bspwm then you might want to try this: https://github.com/riverwm/river If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anyti…

It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample: https://gitlab.freedesktop.org/xorg/xserver/-/issues/386 https://gitlab.freedesktop.org/xorg/xserver/-/issues/333 https://gitlab.freedesktop.org/xorg/xserver/-/issues/380 https://gitlab.freedesktop.org/xorg/xserver/-/issues/249 https://gitlab.freedesktop.org/xorg/xserver/-/issues/260 https://gitlab.freedeskto…

> It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample:

It works fine for me. I gave my reason for why I won't consider switching to some Wayland compositor. None of the bugs you list affect me, so your suggestion I look at a Wayland compositor which would require me to spend time changing my entire config only to be left running XWayland anyway because the terminals I use are X11 based.

It would be a massive waste of my time for no benefit whatsoever.

And this is why X will stay around for a long time: There are lots of us with dependencies like this and no reasons to change things until things starts breaking.

> I don't understand, you were just talking about spending significantly more time rewriting the X server...

Read again. I have not once suggested I'm planning on rewriting an X server. I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X.

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

#216

Post by md8z »

destructionator wrote: post #212
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…

> X is still fundamentally an unsychronized protocol Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands. I've also never seen tearing in X since like 2006.

No, it's not factually false, those fall in the "pile of hacks" I mentioned, and none of them work in all cases, some of them are highly dependent on driver support which is spotty. I can show you various bug reports from the last few years of people still complaining about tearing. This problem is not even remotely close to being solved in X and I don't think it ever will be. Again just look at the bug reports.

Meanwhile, if you plumb atomic page flipping through the whole system and make it mandatory, the chances of having tearing are pretty nonexistent. But you have to drop legacy stuff from X if you want to do that.

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

#217

Post by md8z »

destructionator wrote: post #207
perth wrote: post #46

Earlier quoted context omitted.

Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it: "On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale…

> So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image. X also supports exactly this. Qt uses this information. gtk doesn't for whatever reason, forcing the workarounds. Most the so-called "X limitations" are actually just toolkit bugs if you get into the weeds.

GTK doesn't support it because nobody implemented it. IIRC the Qt support is also pretty buggy and doesn't work on some compositors.

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

#218

Post by md8z »

destructionator wrote: post #209
Seirdy wrote: post #40

Earlier quoted context omitted.

The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago. Advanced mixed DPI also comes to mind. Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.

> The biggest reason is security. X offers no GUI isolation. This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things. These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before th…

I'm really disappointed to see this get mentioned in this context, it's not relevant. At least on debian, ssh -Y and ssh -X has done the same thing since like 2013 because ssh -X is broken and causes clients to crash. The "sandboxing" there doesn't really work. And it's a lot more than a little love that they need to get them working, the whole reason Xephyr sandboxing exists is because Xsecurity and XACE are so broken that it's unusable. You can see more about this in another comment here: https://news.ycombinator.com/item?id=29092612

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

#219

Post by md8z »

destructionator wrote: post #211
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...

> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor... No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).

Yeah you do if you want to have the same window span across monitors. And if you have non-integer DPI scaling then things will probably always be either blurry or inaccurate, that is unavoidable.

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

#220

Post by md8z »

vidarh wrote: post #215
md8z wrote: post #192

Earlier quoted context omitted.

It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample: https://gitlab.freedesktop.org/xorg/xserver/-/issues/386 https://gitlab.freedesktop.org/xorg/xserver/-/issues/333 https://gitlab.freedesktop.org/xorg/xserver/-/issues/380 https://gitlab.freedesktop.org/xorg/xserver/-/issues/249 https://gitlab.freedesktop.org/xorg/xserver/-/issues/260 https://gitlab.freedeskto…

> It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample: It works fine for me . I gave my reason for why I won't consider switching to some Wayland compositor. None of the bugs you list affect me, so your suggestion I look at a Wayland compositor which would require me to spend time changing my entire config only to be left running XWayland anyway because the ter…

I guess you can consider yourself lucky that you're not affected by those bugs? Things are ostensibly already broken and have been for quite some time, some of those bugs are over 15 years old. If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you. And if that's not what you meant then the other stuff is still there if you change your mind and decide to switch.

"I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X."

I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement. Because that is what we are looking at here. Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".

Post reply on HN