Waypipe: GSoC Project Complete(lists.freedesktop.org)
lists.freedesktop.org
Waypipe: GSoC Project Complete
https://lists.freedesktop.org/archives/wayland-devel/2019-August/040819.html
4 comments
I salute Manuel Stoeckl; this is impressive for a summer project. Hopefully this will also put to rest the biggest objection to Wayland adoption.
Totally agree - its an impressive piece of work and strongly recommend any one interested in this area to read the blog posts that were made during the project:
https://mstoeckl.com/notes/gsoc/blog.html
They are definitely worth going through and Manuel Stoeckl deserves a lot of good karma for taking this on.
https://mstoeckl.com/notes/gsoc/blog.html
They are definitely worth going through and Manuel Stoeckl deserves a lot of good karma for taking this on.
[deleted]
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.
These things are managed by your compositor, not Wayland itself. Which compositor are you using?
Really impressive work. What does the latency feel like when running over something not on the local lan?
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.
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.
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.
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.
> 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.
Xft is drawn 100% server side
> But they've decided to go in the other direction
They made the wrong decision.
> 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...
> 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.
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...
> 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.
> 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.
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.
Server side rendering capabilities of X are a relic of the 90s that never evolved and never could evolve..
Because funnily enough, the network transparency of X is in direct conflict with the evolution of GUI applications and toolkits: if a new server-side capability is required, it would only be present in a new version of the X server, and when the X server is remote… well, it could be anything, it could be an ancient version on a system that will never be upgraded, or an alternative implementation like VcXsrv for Windows.
Because funnily enough, the network transparency of X is in direct conflict with the evolution of GUI applications and toolkits: if a new server-side capability is required, it would only be present in a new version of the X server, and when the X server is remote… well, it could be anything, it could be an ancient version on a system that will never be upgraded, or an alternative implementation like VcXsrv for Windows.
There were a lot of X-extensions introduced over the years that are rendered server side. Some are even widely used even today, such as Xft.
Also the ability to upload pixmaps and blit them afterwards as much as you want without causing much bandwidth exists since the earliest version of X11. The offending toolkits are not even using that. They blit client side and transmit the result every time. As I told you, they are stupid.
Also the ability to upload pixmaps and blit them afterwards as much as you want without causing much bandwidth exists since the earliest version of X11. The offending toolkits are not even using that. They blit client side and transmit the result every time. As I told you, they are stupid.
Maybe X11 just doesn’t have the right abstractions. As an example, to this day iOS uses mostly server-side rendering with API basically unchanged for 10 years. Fonts are rendered client-side, but compositing and animations are done out of process.
X11 can do all that. If all else fails you can use GLX to blend some textures together or animate them. The problem is more that there are to many different ways to achieve the same thing. A clean up would indeed be nice but Wayland is exactly the wrong answer.