Remote Desktop Backend Merged into Wayland
New submitter Skrapion writes "One month ago, an independent developer submitted patches to the Wayland's Weston compositor which adds support for FreeRDP, an open-source remote desktop protocol. Now, after six revisions, the remote desktop code has been merged into the trunk. While remote desktop has been prototyped in Weston once before by Wayland developer Kristian Høgsberg, this is the first time Wayland/Weston has officially supported the feature. For a summary of why we can expect Wayland's remote desktop to surpass X.Org's network transparency, see Daniel Stone's excellent talk from Linux.conf.au."
Again... you show that you misunderstand how X works. It is the X client that is shooting bitmaps across the network. If you cannot get the terminology right, your arguments aren't going to be taken seriously.
And if an X application running on the client system is doing that, then, IMHO, the blame lies with the developer of the application and not X11. Perhaps it's the graphics libraries that have been employed for developing the X application that are the main source of all this inefficiency. My guess is that it's things like skins, themes, bizarre fonts, etc. that are probably the biggest reason that bitmaps have to be sent across the wire. It's wrong to blame X11 for developers using bitmaps when drawing objects. It's not X11's fault that developers have taken to using inefficient programming practices. Much like web developers that design web pages that are only rendered quickly when viewed on the same LAN as the server and load so slowly to be all but unviewable by users who don't live next door to the phone company's local office. Maybe having the developers work from home and have to see their work running in an environment similar to that encountered by the vast majority of the application users would have been helpful. I just think that throwing out the infrastructure because application developers got lazy or forgot to test their application in a realistic setting is the wrong solution.
CUR ALLOC 20195.....5804M