
Waypipe: GSoC Project Complete - emersion
https://lists.freedesktop.org/archives/wayland-devel/2019-August/040819.html
======
wmf
I salute Manuel Stoeckl; this is impressive for a summer project. Hopefully
this will also put to rest the biggest objection to Wayland adoption.

~~~
pepijndevos
I agree that it's impressive, but my biggest objection to Wayland is uuuh...
that it doesn't work. This is honestly mostly NVidia's fault, but still. I
have a laptop with dual Intel and NVidia graphics, and there is as far as I
can tell no way to make Wayland understand that my external monitor is
connected to the NVidia card. I tried both Nouveau and proprietary, but then I
switched back to X11 and it worked instantly.

~~~
emersion
These things are managed by your compositor, not Wayland itself. Which
compositor are you using?

------
michaelmrose
Really impressive work. What does the latency feel like when running over
something not on the local lan?

~~~
GrayShade
In a quick test with Picard it feels similar SSH X11 forwarding (using SSH
compression in both cases). But YMMV: in Firefox (perhaps because of my
settings), X11 forwarding is awfully slow, perhaps because of the tab loading
animations. Waypipe works reasonably well.

------
nga_
Impressive work for GSoC project

~~~
brianpgordon
Impressive work period!

------
sprash
This will easily beat X11 forwarding in performance and latency. The reason
however is not because that the X11 protocol itself is bad. The designers of
popular toolkits like GTK and Qt are too stupid to use X11 properly by
introducing many unnecessary round trips and not utilizing the server side
rendering capabilities of X at all.

~~~
ptx
I think this is true, although not because the toolkit designers are "stupid".
If the toolkits were designed in better alignment with the old X11 server-side
drawing model, they could be a lot more efficient.

The problem is that the old model has some limitations that make it
impractical to use these days. For instance, modern anti-aliased fonts need to
be drawn on the client side and sent over as bitmaps. There's also no good way
to do double-buffering or otherwise avoiding the display of partially drawn
frames.

So if the X.org maintainers decided to re-focus on server-side drawing, this
could be made to work better. But they've decided to go in the other direction
and draw everything client-side in Wayland, so that's the way the toolkits are
going to be designed.

~~~
sprash
> For instance, modern anti-aliased fonts need to be drawn on the client side
> and sent over as bitmaps.

Xft is drawn 100% server side

> But they've decided to go in the other direction

They made the wrong decision.

~~~
Jasper_
> Xft is drawn 100% server side

No, that's blatantly wrong. libXft is a client library that uses the X RENDER
extension's Glyphs functionality to upload glyphs rendered by FreeType on the
client to the server. Glyph compositing happens on the server, but that's not
even Xft; just X RENDER.

Again, you can look at libXft, the client-side library, to see that all glyph
rendering is client side:
[https://github.com/freedesktop/libXft/blob/master/src/xftren...](https://github.com/freedesktop/libXft/blob/master/src/xftrender.c)

> They made the wrong decision.

GTK+ tries as hard as it can to use the X RENDER extension to draw all shapes
server-side. Like, _really_ hard to do that; I couldn't find any place where
it was unnecessarily falling back to client rendering. And yet when I looked
at how many GTK+ applications were server-rendered, the number was very tiny.

This is a complex problem a lot of people have worked on, with lots of non-
obvious tradeoffs and the peanut gallery going "we made the wrong decision" is
frustrating.

~~~
sprash
> No, that's blatantly wrong.

Not really "blatantly" wrong. Once the Glyps are transmitted to the server
cache they can be redrawn infinitely without causing much bandwidth or round
trips.

The fact that they are not entirely rendered server side is again a totally
stupid decision. Now even the same font can look completely different on the
same system dependent on which freetype parameters some app developer chooses.
Now the fonts for Gtk, Qt, Wx or fltk apps can all look completely different
(E.g. use different sub-pixel rendering) if not configured properly.

> GTK+

The original GTK+ is not the problem and works actually quiet well. Gtk2.0 and
onward as well as any newer QT version are the problem. Gtk2.0 has many
replacable rendering engines most of them don't care one bit about remote
operation. They are certainly not "trying really hard" to do that.

