7 ms·

Waypipe: GSoC Project Complete

196 points by emersion 7y ago

wmf 7y ago
I salute Manuel Stoeckl; this is impressive for a summer project. Hopefully this will also put to rest the biggest objection to Wayland adoption.
- ptrott2017 7y ago
  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 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 7y ago
  [deleted]
- pepijndevos 7y ago
  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 7y ago
    These things are managed by your compositor, not Wayland itself. Which compositor are you using?
nga_ 7y ago
Impressive work for GSoC project
- brianpgordon 7y ago
  Impressive work period!
michaelmrose 7y ago
Really impressive work. What does the latency feel like when running over something not on the local lan?
- GrayShade 7y ago
  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.
sprash 7y ago
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 7y ago
  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 7y ago
    > 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_ 7y ago
      > 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/xftrender.c 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.

196 points by emersion 7y ago

wmf 7y ago

I salute Manuel Stoeckl; this is impressive for a summer project. Hopefully this will also put to rest the biggest objection to Wayland adoption.

ptrott2017 7y ago
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 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 7y ago
[deleted]
pepijndevos 7y ago
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 7y ago
  These things are managed by your compositor, not Wayland itself. Which compositor are you using?

nga_ 7y ago

Impressive work for GSoC project

brianpgordon 7y ago
Impressive work period!

michaelmrose 7y ago

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

GrayShade 7y ago
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.

sprash 7y ago

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 7y ago
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 7y ago
  > 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_ 7y ago
    > 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/xftrender.c 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.