I don't like it, even a little, and I'm a Linux guy in shells 10 hours a day.
The biggest problem is that X is at too low a level to be useful for primitives, and too high a level to be fast.
If the network transparency were written at the GTK/QT level, and said "draw this widget here", it'd be super-speedy, and it'd be kinda kickass. NXservers do this better.
If it were lower-level, like VNC, it could also be pretty sweet. Because VNC is low-level, you can run it FAST, and get usuable results.
Remote X is in a no-mans-land. It uses primitives that were relavent in 1985, but not today, which means It's FAR slower than VNC.
If sending the bitmaps over the wire is dramatically faster, you're doing something fundamentally wrong.
I like the featureset that X provides, but remote forwarding X today just does NOT work well.
Sure, it's awesome (and has served us well for a very long time), but as hardware and software change, it has placed limitations on how we can compose the logical components of the display server, and can be done separately anyway.
Much like X servers on platforms that don't use X as their display server (and available for practically every OS), you will be able to run an X server alongside Wayland, and run X clients against it from anywhere.
(Plus you can always run rootless remote clients with other protocols such as RDP.)
Wayland may replace the X server that talks directly to your hardware, but it won't replace or discard the utility of network display protocols (X or otherwise).
X sucks at network transparency, supposedly its one redeeming feature. RDP is better. X is slow (xlib requires too many round trips) and doesn't forward things users care about like sound and local devices like printers, USB sticks, cameras, etc. But worst of all, it's simply ridiculous that you still can't move an X client between servers without terrible hacks.
RDP is, ultimately, a bitmap transfer protocol, with some goodies like compression and transfer of only the changed parts.
X11, on the other hand, provides both bitmap and raster transfer. It's up to the application to decide which parts of widgets are drawn pixel by pixel and which are drawn as shapes. With raster transfer, you can get the smallest possible footprint. Also, X11 is asynchronous in default configuration, so round-trip times is not the problem in general case.
As far as anecdotal evidence is valid, I've been using X11 version of Acme [1] over Ethernet for about two years. It was pretty much undistinguishable from running it locally -- virtually no latencies. Granted, the server was just a few switches (perhaps also a router) away, but that's the business case for X11 use.
As for USB, sound etc. transport -- not in X11 itself. But it's available in NX [2], which is X11 with some extensions.
I'm worried X11 protocol could become a `second-class citizen' in POSIX GUI stack. As soon as just one serious application starts depending on screen being on the same machine as the process, others will follow soon and we'll be screwed.
EDIT:
you may also want to have a look at DXPC [3] -- it works surprisingly well over medium-latency, low-bandwidth links like ADSL (with <50kbps upstream). NX is said to be built on top of that.
Sorry, but the X drawing primitives are mostly ancient and obsolete. All modern apps use toolkits which do almost all their own drawing, making X into a glorified bitmap compositor no better than RDP.
X works fine over Ethernet (and guess what, so does RDP!), but anything higher latency becomes painful quickly. NX patches over some of the deficiencies, but it's buggy and the client software has a UI straight from the 90s. Also, the fact that X requires extra software to do decent network transparency proves the point that it sucks for its intended purpose.
You have missed vladimir's reply [1]: mind the XRender. When Qt's (can't speak for GTK) graphics operation go through XRender, it's not just dumb bitmap flying around; it's drwing operations. They may hit hardware directly, or be transported over network.
> Also, the fact that X requires extra software to do decent network transparency proves the point that it sucks for its intended purpose.
I believe X11 was meant for use on LAN, with terminals talking to one beefy machine. To bolster that point, XDMCP [2] by design operates in broadcast domain, which, in typical scenario, is LAN. You need to go extra lengths to connect over routed network, wich may serve as a reminder you are going beyond intented use.
And we agreed it works a-OK on LAN :-)
It's a damn shame X resources [3] became a lost art. Probably thanks to certain prolific cross-platform toolkits.
At any rate, I find it ridiculous that, having a bit of Plan 9 background, I ended up defending X11. Which is old and outdated from my perspective, but still way less than RDP. Bind me /dev/draw over network anytime.
That again may be implementation detail, and may vary upon toolkit version and target platform.
In general, Qt encourages use of QBrush and QPainter to draw on QWidgets. A lot of shape-drawing operations is abstracted; application code supplies coordinates and drawing style and platform is supposed to do the actual operation. Another versatile widget is QGraphicsScene (along with QGraphicsView) which works in terms of sprites and probably maps pretty well onto 2D acceleration of graphic cards.
Under very heavy load you can sometimes see steps of Qt widgets drawing -- it's usually frame by frame (as in, rectangle by rectangle), rather than pixel by pixel.
Thanks for the links, one thing made me curious, can you elaborate on the choice of acme? are you running plan 9? I always thought plan 9 was a great idea but I never found anyone (near my circle or friends) who used it daily.
Plan 9 is UNIX taken so far some things you'd take for granted were changed. Some seasoned UNIX users don't like that. Development is active, as per my [1]
I don't run Plan 9 proper (yet); instead a POSIX port of some of its goodies: the Plan 9 from Userspace [2]. Works on virtually any POSIX OS.
In short, Acme fits me. Fast for common tasks (text navigation and mangling), powerful for ad-hoc text processing.
Acme is a bit of an oddball in UNIX land: strictly a GUI (requires a mouse with three buttons) blended with power of CLI tools and regular expressions. A good deal of text transformations happens via command language derived from sed (should be familiar to any Vi user). If you want to indent a block of text, you select it first and execute Edit s,^, ,g. Alternatively you can indicate the text with regular expressions.
A lot more happens via the good old UNIX pipe -- you can transform text, send as standard input and inject from standard output of a pipeline.
The Bell Labs guys figured some operations on text are done quicker using mouse. Cut/Paste are mouse chords. There is no separate `Copy' -- Cut & Paste back in place is quick enough. You can indicate place (or range) in file via regular expression, but you can indicate it by mouse -- often faster.
Acme yields to scripting very well. A script `learns' of the window (probably a file or directory pathname) it was launched from via the `$%' env variable and often operates on it. Programs are free to open new and modify existing Acme windows via simple `API' consisting of a bunch of files and directories. For me, a few scripts tailored for current project work better than a generic IDE. Any output appears back in Acme, which bodes well with the following:
Acme considers any text a potential hyperlink -- including directory listings and output of any program. Right-click on file name opens the file, on file:line expression opens file at that line etc. Also available file:/regular-expression; you can define more via plumber configuration. In general, clicking on a word causes it to be sent to plumber [3] and interpreted according to text processing rules & existence of files; an URL launches a browser, a man(1) indicator opens manpage etc. If nothing useful can be opened, the text is simply searched for in the current window. To navigate directory/file tree, you click on the names you want to go to.
A middle click executes commands. A dozen of built-in commands are recognized, all else is passed to shell. It's customary to prepare short snippets of shell code in place and execute them with middle click. Possibly appending arguments via a mouse chord.
Acme is a second iteration of GUI editor by Rob Pike; first is Sam [4]. They have a lot in common, especially the comman language.
Wow, thanks for the very good info. Think I will try acme, just to get a felling. Plan 9 from Userspace will be the way for me.
About the "soapdog" well, that is a silly story years ago trying to decide on a nick to register at a BBS and ghostdog was taken, had to decide on the spot because interstate calls were expensive, so looked at a soap bar and soapdog was the nick :-)
Yeah, but it requires porting apps, and if you're doing that anyway why not switch to a modern system without the decades of legacy cruft, like Wayland?
You can, but the client has to support it... if the client is built with GTK+, it can already do it thanks to support built in to the toolkit itself! Try it with gtk-demo. :-)
Because current X implementation is completely screwed up.
Instead of rendering on server and sending only high-level messages like "here be buttons", X's rendering everything on client — even rasterizing fonts, then sending bitmaps over network. Obviously, volumes are huge so is latency. And there isn't even a slight hope of look-and-feel consistency, too (how client on remote machine is supposed to know your GTK theme?)
Wayland may seem weird, but it could be a step in a right direction. Just throw in network transparency at widget toolkit level.
The typical thing is to run the X server locally and the client remotely. There are lots of reasons to do this such as the server possessing special hardware, license managers, fast disks with the data you care about, more memory, more cores.
For my usual desktop tasks, all the 'data I care about' is on my very own hard drive. Also, processing power of my laptop is good enough to not need any 'special hardware' or 'more memory' than I have. That is why I asked why Mr. John Desktoe Ubuntu-user would want to have network transparency. (I realize that this might be different for some bigger installation, but most (Linux-) people just run Ubuntu locally on their Laptops)
The example user might like to use some word processing software, some native email client with big storage, some graphic editing and maybe even some Twitter app. Some people prefer native, installed applications to doing everything in a browser. What do you know, she might even want to do some programming!
X11 is snappy when both computers are on the local network, but as soon as the traffic has to travel over the internet X11 is unusably slow. VNC feels sluggish in that situation but it's still usable. xpra or nx can make X11 usable over the internet. I suspect something like xpra will be created for wayland.
Personally I also use X network transparancy a lot, and I would be very sad to lose that. Apparently some constructive people feel the same way, because looking at the wayland-devel mailing list there there are apparently some people hard at work right now adding network transparency to Wayland.
>Personally I also use X network transparancy a lot, and I would be very sad to lose that.
Taking network transparency out of the core, where it has no business being, does not mean you have to lose it. It would simply need to be implemented in libraries or somewhere at a higher level, with the advantage that the vast majority of us who never use it don't have to "pay" for it.
>Apparently some constructive people feel the same way, because looking at the wayland-devel mailing list there there are apparently some people hard at work right now adding network transparency to Wayland.
This misleading sentence made me nervous that Wayland was just going to be another useless reimplementation of the (IMO, obsolete) X protocol. But [1] seems to clearly indicate that this is not the case. What are you referring to exactly?
Instead of working the way X does, the intent in Wayland is to do all rendering client side (the way things are done in practice under X these days anyway). Did you see the big thread on the mailing list about "Finishing the network protocol"?
> Sans the round tripping, which was the main point of this project.
The "main point" of Wayland has nothing to do with eliminating the (trivial) overhead of network transparency; rather, it's to finally get rid of all the legacy cruft that's accumulated in the X11 protocol over the years.
Much of X11, such as fonts, graphics primitives, and color palettes, is completely unused by modern clients (even remote ones) -- it makes sense to simplify the protocol by dropping such legacy features.
It's good to see Linux finally address one of its biggest (if not the biggest) weaknesses: the display stack. Interesting that several groups have tried this same thing [1] but it wasn't until Wayland that it got traction. Still, I'm happy to see it happening at all.
I don't see the point, if I ever need a Windows like operating system, I can just use Windows.