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
Attachments: