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. :-)
