Content-Length: 23928 | pFad | http://lwn.net/Articles/481953/

FOSDEM: The Wayland display server [LWN.net]
|
|
Subscribe / Log in / New account

FOSDEM: The Wayland display server

FOSDEM: The Wayland display server

Posted Feb 16, 2012 18:16 UTC (Thu) by JoeBuck (subscriber, #2330)
In reply to: FOSDEM: The Wayland display server by angdraug
Parent article: FOSDEM: The Wayland display server

Precisely because so many people care about network transparency, I'm confident that some of those people will actively contribute to efforts to support it. This is free software after all, it's not like we're helpless because Steve Jobs took out our favorite feature.

Perhaps some highly motivated people can put together a design for a kick-ass way to support remote access with Wayland that avoids the problems with the X implementation (too many round trips, too much bandwidth required). A remote access protocol that is aware of structure should be able to achieve much better performance than VNC.

to post comments

FOSDEM: The Wayland display server

Posted Feb 17, 2012 10:54 UTC (Fri) by alankila (guest, #47141) [Link] (10 responses)

I said this before and will say again: toolkit-level network transparency can be experimented with today, whether X11 or Wayland is the display server, and it should yield superior performance, and have some other goodies: for instance, it could render the GUI according to user's locally defined GTK+ theme rather than whatever pixels the server wants to push (because server doesn't push pixels, it will push statements like 'add a button with these attributes inside that container, please').

We should *absolutely* start doing this work, and we might prefer it over X11 even if Wayland never actually lands on our desktops.

FOSDEM: The Wayland display server

Posted Feb 17, 2012 13:22 UTC (Fri) by Tet (subscriber, #5433) [Link] (3 responses)

toolkit-level network transparency can be experimented with today

But why would you want to? The toolkit is absolutely the wrong place to be doing this. As I write this, I have applications open using at least 4 different toolkits. Implementing network transparency in each of them such that it behaves the same in all of my current applications is simply not going to happen. If you believe otherwise, I have a bridge I'd like to sell you...

FOSDEM: The Wayland display server

Posted Feb 17, 2012 14:14 UTC (Fri) by alankila (guest, #47141) [Link] (2 responses)

Maybe this would get people to stop using so many toolkits...

In any case, in Wayland's architecture -- which does not define rendering at all -- there is no other obvious way to do the thing except by repeated bitmap snapshots of the window contents followed by costly analysis and encoding of the difference. It will suck.

FOSDEM: The Wayland display server

Posted Feb 23, 2012 19:31 UTC (Thu) by wmf (guest, #33791) [Link] (1 responses)

I think it's too early to declare that compressed bitmaps will suck. For example, the Sun Labs SLIM project found that a simple VNC-like protocol used less bandwidth than X11.

FOSDEM: The Wayland display server

Posted Mar 1, 2012 13:07 UTC (Thu) by nix (subscriber, #2304) [Link]

In what use case, though? Easy stuff like a canvas with stuff being drawn on it, or hard-but-common stuff like a scrolling xterm window filled with text?

FOSDEM: The Wayland display server

Posted Feb 18, 2012 2:24 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Toolkit-level transparency is actually even used (somewhat). There's RSWT: http://rswt.sourceforge.net/screenshots.html and several similar projects (like Remote SWING).

Making a remote GTK or QT UI is feasible and should not even be hard. AND since in that case only very little data is going to be transmitted, it can actually be useful.

FOSDEM: The Wayland display server

Posted Feb 18, 2012 21:04 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

I would think that the toolkits would also be able to use the local D-Bus sessions, ssh-agent sockets, etc. instead of also having to forward those in addition to the X session socket (or just leaving it as-is and always hooking up to the remote one).

You could have automatic gvfs and KIO slaves made for wayland-local:/ and wayland-remote:/ protocols so that the local and the remote filesystems could be accessed. There's a lot more than just pushing pixels across a pipe to get the full experience of running a remote application as if it were local.

FOSDEM: The Wayland display server

Posted Feb 20, 2012 22:11 UTC (Mon) by HelloWorld (guest, #56129) [Link] (3 responses)

> I said this before and will say again: toolkit-level network transparency can be experimented with today, whether X11 or Wayland is the display server, and it should yield superior performance, and have some other goodies: for instance, it could render the GUI according to user's locally defined GTK+ theme rather than whatever pixels the server wants to push (because server doesn't push pixels, it will push statements like 'add a button with these attributes inside that container, please').
That sounds nice in theory, but I doubt it'll work. For example, what if the client uses GTK+ version n, and the server only has version n-1 available?
Also, you'd need to run one server for Qt, one for GTK+, one for EFL etc. etc., that's going to be a nightmare.
What I'd like to see is a rendering server that allows clients to upload little programs that know how to, say, draw a button, and then in order to draw a button, they only have to tell the server to run that program they've uploaded before using such and such parameters. I think DisplayPostscript worked like that. That would at least get rid of the need to run multiple servers for the toolkits, as they could more or less define their own specialized protocol.
However, I'm not sure that'll work either. It would probably require rather substantial changes in the toolkits, and it would probably be hard to port existing theme engines etc. to such a new paradigm, at least if one wants to exploit this kind of technology to a significant degree. Also, we already have similar technology: JavaScript and Canvas/WebGL. GTK+ already features the Broadway backend which renders into a browser window, though I'm not sure how much work is actually done on the client or on the server side.
So clearly, this is a hard problem to solve.

FOSDEM: The Wayland display server

Posted Feb 21, 2012 11:52 UTC (Tue) by alankila (guest, #47141) [Link] (2 responses)

Yes, it is a hard problem to solve, especially if you want to solve it for all software there is... I'd personally settle for far less: it's enough to me that *one* reasonably good toolkit does it, especially if it's GTK+ or Qt: most software already exists for both of these toolkits, so you just have one more reason to avoid the worse one.

FOSDEM: The Wayland display server

Posted Feb 21, 2012 13:23 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

I disagree with this. I'm a KDE user, yet I also use quite a few GTK+ applications because their Qt alternatives either don't exist or suck, for example wireshark, emacs and leksah. Considering this, a remote GUI that can't handle at least GTK+ and Qt would be next to useless in my opinion.

Also, you didn't explain how to solve the issue of differing GTK+ versions between the client and the server.

FOSDEM: The Wayland display server

Posted Mar 1, 2012 13:10 UTC (Thu) by nix (subscriber, #2304) [Link]

For that matter, I still run one single Xt application: Emacs. That's because Gtk dumps core if its X session goes away, making the emacs server mostly useless: the bug for this has been open for years and appears unfixable. Now maybe this problem will vanish with Wayland (as it relates to Gtk keeping stuff on the X server but not keeping track of it so it can resend it if the X connection dies)... but maybe not. Demonstrably the Gtk hackers do not care about use cases like remotely running an application which maps multiple windows, then unmapping all the windows so you can suspend the machine on which the display is done.

Because, after all, saving power by suspending your machine when not in use while leaving your processes running on another machine so they can keep doing background jobs is a rare use case, unless you jam the word 'cloud' in there, whereupon it suddenly becomes immensely important. Or something.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/481953/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy