On Tue, Aug 2, 2016 at 1:08 PM, Silvan Jegen <s.jegen_AT_gmail.com> wrote:
> On Tue, Aug 02, 2016 at 08:41:57PM +0200, FRIGN wrote:
> > On Tue, 2 Aug 2016 20:33:39 +0200
> > Silvan Jegen <s.jegen_AT_gmail.com> wrote:
> >
> > Hey Silvan,
> >
> > > One can argue that having a simple protocol *is* the suckless part of
> > > Wayland (dont forget Xprint[0] :P). The Wayland protocol also does not
> > > allow for communication between clients directly[1] but only through
> > > the Wayland compositor.
> >
> > yeah, but omitting the rest is not suckless, it just turns everything
> > into a big mess. You might say anything about X.org, but at least you
> > can more or less rely on a set of features available to you, even if
> > they are "default" XFree86 extensions.
You are comparing a specific implementation of X11 (Xorg) with a
protocol (wayland).
If you chose to implement your own suckless X11 server, you'd still
have all the problems you are describing (rendering, buffer
management, input handling, joysticks, etc), and probably a lot more
because of legacy X11 baggage.
> > > I see two main issues that stem from switching to Wayland.
> > > 1. With Wayland there will be no non-compositing desktop.
> >
> > I don't see this aspect too critically. See how Wayland performs vs.
> > X in limited environments[0].
>
> I always assumed that having a compositing window manager has negative
> performance impact but at least according to
>
> https://blog.martin-graesslin.com/blog/2013/05/compositing-and-lightweight-desktops/
Xorg is a compositor too... At the end of the day, *something* has to
combine all your windows into a single frame to display them on your
monitor.
I didn't read the article, but presumably the slowness is due to
Xcomposite redirecting to some compositing windowing manager. If the
display server does the compositing (as in normal Xorg, or a typical
wayland server), there is no such problem.
> > > 2. Since rendering is done client-side and there is no Xlib, it may be
> > > harder to get pixel on your screen if you don't want to use one of
> > > the big GUI libraries like Qt or GTK2/3/++/whatev.
> >
> > Yeah, very good point. Also, clients cannot rely on compositor
> > features, because each compositor can do things differently. There
> > really is no simple way to write software and making it deliberately
> > hard almost makes you believe its a GTK/Qt conspiracy of some sort.
>
> > > As a non-expert in this space I am not sure the Wayland future is
> > > looking that bleak though.
> > > Velox[2] does not look bloated to me and wayland-enabled st[3] is only
> > > barely larger than the current X11 version's git tip (though the
> > > wayland version depends on wld[4]).
> >
> > How can you compare the two? You need a third-party library (wld) to
> > get shit done. Just wait down the line how much of a fucking mess we
> > are going to have!
With X11 and Xlib, you need an X server that implements every drawing
routine you might want to call.
But maybe you are arguing for server-side rendering over the display
server connection. I think it's simpler to just have the client do the
rendering, which it can do however it pleases.
--
Michael Forney <mforney_AT_mforney.org>
Received on Tue Aug 02 2016 - 23:17:46 CEST