Message: previous - next
Month: September 2013

Re: Re: Re: [trinity-devel] My opinion on Trinity project quality

From: Martin Gräßlin <mgraesslin@...>
Date: Thu, 19 Sep 2013 15:47:14 +0200
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 

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 

That was the technical background, now I go to explain a little bit more 
> 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 

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