Re: OSEF

1) Les dev de Xorg qui embrassent Wayland ne sont pas neutres, ils défendent leur décision, on n'est pas obligé de répéter bêtement ce qu'ils disent..

Ben en face on confond toujours bêtement transparence réseau et affichage à distance, donc bon.

2) tu n’arrête pas de répéter la transparence réseau ci, la transparence réseau ça, mais tout le monde le sait que la transparence réseau ça n'existe pas vraiment puisque la bande passante et la latence sont totalement différentes ET CA A TOUJOURS ÉTÉ LE CAS (la latence tu sais ça n'a pas beaucoup changé..).

Vous voulez pas comprendre non plus que quand les fenêtres sont complexes (thèmes, thèmes d'icônes, décorations, polices complexes, animations), et qu'on se tape un protocole synchrone et bavard, la latence explose ?

A partir de là, quelle est la définition raisonnable du terme que tout le monde utilise?
Un protocole d'affichage graphique qui intègre l'affichage distant par défaut, point.

Donc quand le dév de Xorg dit qu'il n'est pas network transparent mais juste network-capable, il ne connaît pas le protocole X11 ?
Dur, pour quelqu'un qui travaille dessus depuis 10 ans.

Donc
1) Wayland ne fournit pas ça. On peut ajouter des surcouches à Wayland (dont X), l'implémenter dans le serveur d'affichage (sous-optimal bien sûr, par rapport à une gestion dans le protocole), mais Wayland lui-même est purement local.

2) X11 a l'accès distant en natif lui, même si c'était un accident (quoique vu le nombre d'universités qui se servaient de cette fonctionnalité, c'était un accident très utilisé), même s'il est sous-optimal..

La capacité d'utilisation à distance est prévue dans l'architecture même de Xorg/X11. La transparence réseau, ça, c'était un accident :

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.

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.

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.

(ça finira bien par rentrer dans vos têtes dures)

Ceci dit X s'est amélioré avec le temps pour l'accès distant: cache de glyphe XRender qui te permet d'afficher efficacement du texte, XCB asynchrone vs XLib synchrone, là malheureusement les toolkits ont traîné les pieds pour passer à XCB..
De manière amusante c'est Wayland qui a poussé les dev Qt a passé à XCB pour Qt5 (car les deux sont asynchrones), donc l'affichage distant sous X avec Qt devrait s’améliorer grâce à Wayland :-)

Bien.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)