Waypipe Offers A Transparent Wayland Proxy For Running Programs Over The Network

[quikee]

1. It's even more of a shame that the alternative formats, aside from Theora, are far too slow to encode to be usable.

That's common misconception about codecs. Encoders don't need to use all of its tools and search as exhaustively for a better solution as they do when encoding a video file for maximum compression efficiency, and this usually what people see when thinking about codec speed.

VP8 and VP9 in libvpx have a real-time mode, where it is as efficient as possible when encoding the stream in real-time, however, compared to Theora both have the potential to be more efficient at the same speed Theora encodes (if somebody puts the effort in to run the encoder down to Theora level). The main problem with VP8 and VP9 is that we're more or less stuck with libvpx, which sadly doesn't squeeze as much from those two format out as it could (also for the real-time use case). But then we have some VP8 and VP9 hardware codecs available, which can be used for real-time now.

Looking ahead at AV1 I think we'll see some really great real-time encoders (rav1e for example). AV1 also has some coding tools that were added explicitly for screen content, so the efficiency could be drastically better than VP8 and VP9 (also bigger transform sizes help a lot with screen content, with many big areas where the same color and CDEF - deringing filter should help sharp edged areas - like text).

[oiaohm]

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Network-Transparency

Wayland over network is not new. Its been having the development time to go past the prototypes to final functional.

[MaxToTheMax]

Well this thread is a shitshow as expected, but this legitimately was one of the big things keeping me on X11 and this is actually great news for me.

For all that people complain about the performance and how it's not really network transparent, the truth is X over SSH works pretty well anyway. The ability to freely mix windows between computers is awesome and it's worth putting up with bad performance for. But I'll be happy to ditch X11 for all the same reasons as everyone else, once this functionality is stable.

[kenjo]

I don't get why people would want to emulate least useful feature of X11 that can be done better with VNC.

Why someone would use VNC over ssh -X I will never understand. VNC is a pain int the A** to use compared to X over ssh.

[bwat47]

Is VA-API not supported in Wayland? Even ancient intel chips can do h264 in hardware, and it could greatly reduce cost of encoding video. I think there should be more options for video formats to better suit certain applications. Sometimes it might be desirable to have lossless compression, and sometimes it might be possible to get away with a lower framerate.

I don't get why people would want to emulate least useful feature of X11 that can be done better with VNC.

VA-API does work with wayland, but only if your video player is using wayland natively (it does not work with Xwayland)

[oiaohm]

Why someone would use VNC over ssh -X I will never understand. VNC is a pain int the A** to use compared to X over ssh.

Really if you take away ssh command like -X flag. Both ssh has to port forwards a port. You need server or vnc client program at the end you run ssh from.

So VNC being a pain in an ass over ssh is large part ssh program not set up do it well.

VNC has things like https://tigervnc.org/ that allows you to use opengl applications and the like remotely. This stuff does not work well with X11 at all. Also losing your connection VNC server on the computer you are connecting to can nicely stay running even than ssh was cut. X.org server by self this is not the case connection cut termination of programs.

Yes ssh -X comes a little more complex once you have to be puttingxpra into mix so you are not killing applications when you lose connection at this point starting a vnc server on the remote end is not that big of deal. Yes the fact ssh does not have a flag to pass the vnc port though that is a problem and the fact you have to start the vnc client your end is a problem.

Remember wayland solutions are starting to start xwayland on demard. There is no reason why as ssh solution could not be made that starts a rdp/vnc client on demard and on the remote end provided means for current vnc server to use to report it presence after connect. The reason why ssh -X is simple to use is really lack of development time put into taking the sharp edges off using vnc or rdp with ssh. waypipe/vnc/rdp over ssh promises to use less network bandwidth than using X11 over ssh. X11 over the wire protocol is horrible bad at being compression as well as basically not being compressed. Horrible reality the image format X11 send over the wire by protocol basically is like lets take a binary image and make it 4 times bigger this effectively undermines compression.

[microcode]

Sounds like Wayland to me.

What? What are you even smoking? Touch screens and high resolution scrolling events have worked great in libinput since around the time Wayland even became a thing. In my experience, it has not been uncommon that I start up Weston on a new device, and the touch screen Just Works™.

[kenjo]

Really if you take away ssh command like -X flag. Both ssh has to port forwards a port. You need server or vnc client program at the end you run ssh from.

Clearly I'm not meaning the work the computer needs to do but the user. If I use ssh -X to remotely connect I do not even need to start any GUI if I do not want to but if I need it I simply run the command I need. Zero config zero planing everything just works. And I get only the program I want not a "desktop" window with lots of crap I don't want to start. Also very small risk of abandoned left overs running month after someone last used it and this happens a lot with vnc on shared servers until I removed vnc serve that is.

For situations where I know I want do work for a long time remotely and need a GUI i use x2go with session type set to single application.

[oiaohm]

Clearly I'm not meaning the work the computer needs to do but the user. If I use ssh -X to remotely connect I do not even need to start any GUI if I do not want to but if I need it I simply run the command I need. Zero config zero planing everything just works. And I get only the program I want not a "desktop" window with lots of crap I don't want to start. Also very small risk of abandoned left overs running month after someone last used it and this happens a lot with vnc on shared servers until I removed vnc serve that is.

My point is that ssh -X did not always exist. That pass across is not really a reason to keep x11. It is a reason we need to have some form of network protocol for graphics integrated into ssh.

VNC server remaining running for too long is not as high of risk as it use to be logind adding logout clean up. VNC server started by the sshd because you connected with particular flag in the running usersession could be autoclean up by either logind or sshd. Notice this is basically alter sshsystem and you could recreate the ssh -X behaviour with any over the network graphics protocol.

I call the ssh -X stuff a itch problem that the resources have not been put into fixing yet. I am not against what you want just it does not really mean we need to keep X11 todo it going forwards.

[jpg44]

I don't get why people would want to emulate least useful feature of X11 that can be done better with VNC.

Having app<->server network transparency is extremely useful and covers different use cases than whole desktop network tranparency.

VNC exports the whole desktop and does so by scraping the video front buffer for the entire desktop session and sending the entire bitmap to the client. This is actually somewhat inefficient. For a headless/remote only session it would require software rendering be used. Plus does not cover the use case of where you would want only single application displayed to another computer, not the entire desktop session.

An ideal app<->server network transparency would work by the app sending OpenGL and Vulkan commands over the wire and for rendering and rasterization of those commands to happen on the computer the app is to be displayed to. This way hardware rendering can be done on the computer where the application is to be displayed to, and it also can avoid sending large video buffers for the entire window over the wire, instead, more vector data can be sent. You could also have a bitmap window buffer mode as well if you want software rendering to be done on the clients machine, but which to use should be made a runtime option. This can be useful if you have applications running on different computers but you want them all displayed to a single display on a different computer.