Hacker News new | ask | show | jobs
by md8z 1689 days ago
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't really make any sense to me. 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. There is zero will to actually do that, I've heard similar suggestions to make X12 for the last 15-20 years, and nobody has ever cared enough to do it because the only reason anyone ever uses X is for compatibility with old software. Once you take that away, there's nothing left. The closest existing thing to an X12 is, well you guessed it, Wayland.

1 comments

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

You need to double buffer the clients or you will still get flickering and noticeable redraw. You can see this with older X clients. It actually is a protocol issue because X was explicitly designed to do this.

You are presenting this as if it's some kind of decision between "break compatibility" and "start from scratch" when really those are a lot closer than you think. Realistically, most of the X server is still overdue for a major rewrite/refactor. But I really doubt anyone would ever volunteer to do that work at this point.

No, you don't need to double buffer the clients if the clients are properly designed and flush the request queue cautiously rather than willy-nilly, and the server takes a minimum of care rather than just stupidly processing requests one by one. None of the clients I use give flickering or noticeable redraw.

There may certainly be cases where it'd be harder to avoid, but realistically this hasn't been a problem for most X users for decades. Of course I'm not doubting that it is a problem for some, but it's not for me and haven't been since the 90's.