On Thursday 19 September 2013 13:40:07 Russell Brown wrote:
X11 is unfortunately although claimed otherwise completely unsuited for terminal setups. It mostly works because bandwith is enough, but in general it just sucks.
Hmmmm.... it's suited us since the mid 1980s !
doesn't mean it's a good thing ;-)
I'm going to explain a little bit more now as I think that can be of general interest as there are misconceptions about "Qt4 being slow". Understanding what's going on, can help here.
Let's go back into the 80s of the last century when X got invented. Back then Unix didn't support shared libraries. Drawing functions on the other hand were quite complex and adding it to each process was not possible due to memory constraints. Therefore a client-server approach was used so that all the drawing functionality would be in the server and the clients would only need a considerably smaller library to use the protocol to communicate with the server.
That's how X became network transparent, but it has never been the aim to be so, it's rather a side-effect of the constraints by the operating system and hardware back in those days.
If one works with the protocol (and I do so each and every day, a printout is just in the moment next to my keyboard on the desk) one notices that it's not designed for network. The protocol has huge overhead, doesn't support compression, is more sync than async (very bad for network), etc. etc.
What X provided for rendering were the most basic primitives for rendering what was supported in the 80s and what was invented and not patented in the 80s. Yeah quite some common algorithms used today didn't exist back then and the patents luckily expired by now. In the 90s this started to get painful and applications wanted to be better. Slowly, slowly things got replaced by new extensions (e.g. XRender extension in 2000) or moved directly into the clients (e.g. fonts).
In the last decade moving to the client went even further. All modern toolkits render completely client side, that is use either CPU or OpenGL to render into a local buffer and just transfer the resulting image to X. And that's the point where the network transparency really hits its limits. What we are now doing is transferring video over X - without any compression, neither loss- less nor lossy). In such a situation VNC provides clearly the better choices. The end result of this trend is Wayland which doesn't have a server side rendering component any more.
Obviously one can say now that everything used to be better in the past, but there are reasons why it's done that way. CPU or OpenGL is just faster on a local machine which is as of today the majority of systems. The exchange of the image data is extremely fast on a local system as one can use the SHM extension and just use a shared memory segment as the rendering target. So the local usage increases while the remote capabilities go down. In the discussion about Wayland one can see again and again that people complain about it, but nobody "in charge" cares about it, because X was never meant to be used that way.
That was the technical background, now I go to explain a little bit more inline.
Obviously we have 'enough' bandwidth for TDE but not enough for KE4/QT4. That might sound like a backhanded compliment but it's not intended that way; I'm just saying it as I found it.
Qt 4.(0-7) and Qt 3 and not really different in that regard. Since 4.8 rendering has switched completely to client side by default. If you are using Qt with network transparency: ensure that the graphics system is set to native!
But, KDE4's visual style is way more complex. This includes everything: icons, widget style, window decorations and most important: animations. Especially Oxygen is very complex (even on a local system it contributes quite a lot to resource usage) and uses animations. The radial gradient on the global window is slow in X and by that completely unsuited for network transparent usage. Therefore: the flatter the style the better. A general recommendation is to use the Plastique style as widget style and Laptop style in window decoration (don't use Plastik, it uses strong gradients, too).
Animations are problematic as they are dependent on the connection to the X server and get slowed down by roundtrips. KDE 3 was rather static and didn't animate much (I assume that you disabled the tooltips of Kicker). Animations mean that way more data needs to be transferred to the server and thus one easily hits bandwith limits. There is a global setting to disable the animations, though it's not honored by all applications: systemsettings -> Application Appearance -> Style -> Fine Tuning (tab) -> Graphical effects (dropdown)
KDE4/QT4 seems to be aimed elsewhere than our sort of usage.
hardly any software written in the last decade is suited for that, because as I explained X is not suited for it.
It's sadly not alone there with things like Firefox and Openoffice assuming that the display device has both a lightspeed connection and infinite resource.
Especially Firefox is no surprise. The complete content is considered as one canvas and the modern web is just updating all the time. On a local system it doesn't matter, but on a remote it means transferring video data for which X is not suited for. The same more or less with OpenOffice. The rendering is probably done client side, so it transmits the complete document view as one image to X whenever it changes. If you are a fast typer that will be painful.
The whole concept of X11 client (lots of resource typically running on a powerful server grade computer) and X11 server (limited resource merely a device to provide a mouse/keyboard and screen) seems to have been forgotten.
No :-) It had never been considered and there are better ways today. Think of the broadway HTML capabilities of GTK which gives you for example OpenOffice in a browser.
On a positive note, you offered to tell me how KDE4 can be configured for a Terminal Server environment and I'll take you up on that; if only for my own education and to find out what I, and many others it seems, did wrong.
The general recommendations as already mentioned in this mail summarized: * ensure graphics system is native * disable all animations (everywhere) * don't use Oxygen or any other heavy style - neither as window decoration nor as widget style * switch to a less detail icon theme, best disable icons globally for toolbars, menus, etc. Each icon needs to be transferred uncompressed * stick to an older version of KDE SC (max 4.8 I'd say), the latest ones use QML and are probably ignoring the animation settings everywhere because it has become so easy to do animations.
However, if TDE carries on the way it has been then I can't see myself moving away from it.
My personal advice is to reconsider the setup and think about whether X is the proper choice. If you still think X is the proper choice rethink what you want to use. Both GTK and Qt have moved away from using X for rendering, so you need something extremely simple which uses plain old X for everything. Maybe openbox is a solution - LXDE, though, isn't as they also switch to Qt.
Cheers Martin