User: Password:
|
|
Subscribe / Log in / New account

Wayland explanations are STILL confusing and worrying users

Wayland explanations are STILL confusing and worrying users

Posted Jun 11, 2013 17:05 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Wayland explanations are STILL confusing and worrying users by david.a.wheeler
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)

It's the definition of "transparency" that is one thing that's tripping everyone up because while it might be easy to use, remote rendering is not actually transparent to the _application_, it has to know which rendering methods are available and needs to maintain two different code paths for shared-memory/DRI and remote rendering. As you point out modern toolkits tend to just produce fully rendered pixmaps and not use the Core X11 drawing primitives, so applications are reduced to just shuffling pixmaps around, inefficiently, for remote use.


(Log in to post comments)

Wayland explanations are STILL confusing and worrying users

Posted Jun 13, 2013 11:20 UTC (Thu) by sorpigal (subscriber, #36106) [Link]

I'll define "transparency" the way that it matters:

1. When I execute an application capable of displaying a GUI it appears on my local screen no matter what machine I am logged in to.

2. When I write a GUI application in the most naive possibly way it will work as described in (1) without me thinking about it during development.

If I write a GTK application today I don't have to put in a single line to get support for remoting (I don't have to plan for it) and if I run it on a remote system it displays locally without me, the user, having to configure anything. That's transparency. It's perfectly okay if the toolkit handles the hard work for me as long as it's easy enough that all toolkits are likely to include support.

Based on this definition:

Does Wayland support network transparency?

Is there a commitment by current Wayland developers to supporting network transparency?

But X can't do that ...

Posted Jun 13, 2013 13:48 UTC (Thu) by Wol (guest, #4433) [Link]

Not today anymore ...

Okay, I run KDE not Gnome, but the blame has been laid firmly at the feet of dbus - a Gnome innovation ...

The only way I have managed to get remote apps to work is to do a remote login and forward the entire session - any attempt to do a "DISPLAY=... command" just keels over.

And even that doesn't work over Cygwin - the login used to regularly fail half way through, and now if the screensaver cuts in I can never recover the desktop - I just have to close X and start again...

Cheers,
Wol

Works for me

Posted Jun 13, 2013 15:33 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

I routinely use X to access remote systems. So, it "works for me". Sorry it's not working for you.

Works for me

Posted Jun 26, 2013 6:21 UTC (Wed) by paulj (subscriber, #341) [Link]

Ditto.

Indeed, for me X works better than VNC, over a wifi connection that has OK latency but unreliable bandwidth. VNC is annoying to use over this, X is fine - you wouldn't know the window was a remote one using it!

But X can't do that ...

Posted Jun 13, 2013 17:42 UTC (Thu) by dlang (subscriber, #313) [Link]

Not all applications use DBUS

The fact that Desktop Environment authors seem to feel that every application, no matter how trivial should use DBUS is yet one more example of problems in that space.

But X can't do that ...

Posted Jun 14, 2013 14:22 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I use KDE applications like kontact or similar on remote X displays routinely. Sorry that it doesn't work for you.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 11:41 UTC (Tue) by nix (subscriber, #2304) [Link]

As you point out modern toolkits tend to just produce fully rendered pixmaps and not use the Core X11 drawing primitives, so applications are reduced to just shuffling pixmaps around, inefficiently, for remote use.
If they're using the render extension properly (which they are) this is an entirely inaccurate description of how textual regions are handled. The bitmaps comprising the textual glyphs are *not* sent repeatedly over and over again in repeated bitmap shuffles, but just once.


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