URL: https://linuxfr.org/users/steckdenis/journaux/en-finir-avec-la-lourdeur-de-kde
Title: En finir avec la lourdeur de KDE
Authors: steckdenis
Date: 2010-01-28T18:53:17+01:00
Tags: firefox
Score: 64
Bonjour,
Depuis la sortie de KDE 4.0, des milliers de gens se plaignent de sa lourdeur, et de ses performances aléatoires. En effet, autant il peut marcher fluidement sur un vieux Pentium 3 chez quelqu'un, autant un autre rapporte qu'il se traîne comme un éléphant sur une machine dernier cri.
Les pilotes graphiques ont été pointés du doigt dès le début, mais tout le monde n'a pas compris ce que cela impliquait. Il a été conseillé à beaucoup de personnes de désactiver les effets graphiques de Kwin, mais ça n'a quasiment rien corrigé la plupart du temps.
**Fonctionnement de la couche graphique de Qt**
Cette partie est un peu technique, mais pourrait vous intéresser. Elle se base sur les différents articles cités en haut de [ce billet](http://labs.trolltech.com/blogs/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/) sur le blog de Trolltech.
Qt est une bibliothèque portable, qui s'occupe de beaucoup de choses, dont tout un système graphique (nommé Arthur, et j'insiste sur le fait que Qt est un **framework**, pas simplement une **bibliothèque graphique**). Du fait de la portabilité de Qt sur différents systèmes d'exploitations (GNU/Linux, Windows, Mac, des téléphones mobiles, etc), la couche graphique doit être adaptée à l'architecture cible.
Pour les applications, il n'y a rien à faire. C'est seulement Qt qui utilise en interne des _backends_.
Sous GNU/Linux, le backend X11 est utilisé. Il transforme les opérations de dessin de bas niveau de Qt (cercles, texte, images, etc) en instructions **XRender**, ce qui permet d'utiliser l'accélération matérielle de la carte graphique.
Un backend OpenGL est disponible pour quasiment toutes les architectures. Là, ce sont des shaders et des opérations OpenGL qui sont utilisées, pour encore mieux tirer profit de la carte graphique.
Il existe aussi des backends pour Mac OS X (Cocoa) et Windows (DirectDraw, mais on n'en parle pas beaucoup, donc je ne suis pas certain qu'il est disponible en production).
**La faiblesse de XRender**
Le problème vient justement du backend X11. D'ailleurs, ceux qui ont utilisé KDE sous Windows ont peut-être remarqué à quel point il est plus rapide sous cet OS que sous GNU/Linux, du moins graphiquement (changement d'onglet dans Konqueror, ouverture d'une application, navigation dans les menus, Plasma). En effet, X11 utilise XRender, qui accélère très bien les «grosses» opérations graphiques, comme par exemple un énorme cercle plein dessiné sur tout l'écran.
Malheureusement, ce n'est pas ce genre d'opérations utilisées par Qt. Dessiner chaque contrôle graphique d'une application Qt nécessite plusieurs dizaines d'opérations, même pour un simple bouton. Seul l'horrible thème Windows95, inclus avec Qt, est suffisamment simple pour profiter de XRender (un bouton est un rectangle avec 4 lignes dedans pour le relief, et du texte).
KDE, par contre, avec son thème Oxygen et ses effets en tous genres est bien trop complexe pour XRender. Dessiner un bouton Oxygen, avec son ombre, son relief, ses effets, la petite illumination nécessite plusieurs dizaines d'opérations graphiques, de petites opérations (une ligne de 3 pixels, etc). Ainsi, bien plus de temps est passé dans Qt et dans XRender pour préparer le dessin que dans la carte graphique pour le rendu. Il y a également bien plus de trafic entre l'application et le serveur X.
XRender est donc la source de la lenteur de KDE, et des petits _freezes_ qu'on peut ressentir quand une lourde opération graphique est lancée (premier affichage d'une fenêtre, changement de bureau virtuel quand la composition est désactivée, changement d'onglet dans Dolphin, Konqueror ou autre).
**OpenGL à la rescousse, ou presque**
Le but du backend OpenGL est de corriger ce problème. Malheureusement, tout ne va pas comme les développeurs le souhaitent. OpenGL pose les mêmes problèmes que XRender (plus de temps passé à la préparation qu'au rendu), et est surtout très incomplet et très mal supporté avec des pilotes libres, se limitant parfois uniquement à OpenGL 1 alors que la version 3 est disponible depuis longtemps.
Le rendu avec OpenGL est donc tout aussi lent qu'avec XRender, bien plus lent parfois (expérience perso : inutilisable sur une ATI Radeon X1250 intégrée avec le pilote libre RadeonHD).
De plus, le backend OpenGL est encore quelque-peu expérimental, et des erreurs de rendu peuvent apparaître (zones floues ou bruitées, éléments absents). OpenGL ne supporte pas non-plus certaines éléments de l'API graphique de Qt, ce qui lui demande de faire le rendu lui-même. Le gain est nul, et même négatif puisqu'il faut rapatrier dans Qt l'image calculée par la carte graphique, ce qui est exessivement long.
**La solution, Raster**
Heureusement, Qt dispose d'un backend Raster. Ce backend traite uniquement des images en RAM, et fait tout lui-même, sans la moindre accélération matérielle.
Cela peut sembler sous-optimisé, mais c'est en fait le meilleur des backends. En effet, il n'y a aucune phase de préparation, et ce backend est optimisé pour tirer parti des instructions multimédia disponibles sur les derniers processeurs.
Il est également l'implémentation de référence, ce qui veut dire qu'il se comporte très exactement comme les développeurs de Qt le veulent.
Au final, il a tout pour lui. Il est extrêmement rapide, et très stable. Son rendu graphique est impeccable, et très approprié à ce que demande KDE, c'est à dire le rendu de nombreux petits éléments, dont des dégradés.
**Utiliser le système raster**
Qt est bien conçu, et tester Raster ne nécessite qu'une simple manipulation.
Il vous suffit de lancer une application à tester dans une console, en lui passant le paramètre «-graphicssystem raster». Par exemple
konqueror -graphicssystem raster
lance Konqueror en utilisant le mode Raster.
Si vous appréciez ce moteur, et que vous souhaitez l'utiliser (lisez cependant ce journal jusqu'à la fin, je n'ai pas encore tout dit), il vous faudra néanmoins recompiler Qt (aïe), en n'oubliant pas de passer «-graphicssystem raster» à la commande ./configure. Je vous conseille, si vous sautez le pas, d'utiliser [KDE Qt](http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#Qt), qui contient des patches intéressants. De plus, la manière de compiler décrite sur ce wiki vous permet de ne pas sâlir votre /usr, mais d'installer Qt dans votre /home.
**Quelques inconvénients de Raster**
Pour introduire cette partie, je vous conseille de jeter un oeil au journal [Chromium est bien plus lent que FireFox](https://linuxfr.org//~yellowiscool/29299.html) (en passant au-dessus de tous les trolls bien entendu).
XRender a bien un avantage : il est léger en bande passante. L'application Qt ne fait que demander à Xorg de dessiner sa fenêtre, ce qu'il fait avec plaisir (perso: en consommant 400Mio de RAM au passage. Avec Raster, il n'en consomme plus que 26,7 Mio d'ailleurs :-) ). Il n'y a donc pas de transfert d'images, hors icônes et petites images utilisées ailleurs.
Avec Raster, c'est bien différent. Qt construit son image dans son coin, pixel par pixel (mais très rapidement et très proprement), puis l'envoie d'un coup à Xorg. En local, aucun problème. Un système de mémoire partagée est utilisée, et Xorg envoie directement le tout à la carte graphique, comme il fait avec les images qu'il produit lui-même. C'est même ce qu'il sait faire le mieux.
Par contre, sur le réseau, c'est plus embêtant de faire passer, à chaque modification d'une fenêtre (caractère tappé, etc), l'équivalent d'une grosse Bitmap non-compressée de la taille de la fenêtre.
Vous allez me dire que ce n'est rien, et que personne n'utilise le réseau. Vous avez raison, mais ce n'est pas tout.
**NOTE** : La partie qui suit semble ne plus se vérifier sur mon ordinateur, quand j'utilise Qt-KDE trunk. En activant le greffon KWin qui va bien, j'ai pu constater que seules les parties réellement modifiées d'une fenêtre sont envoyées à X, ce qui est très bien. Ce que je dis se rapporte à une version antérieure de Qt, que j'ai eu l'occasion de tester il y a quelques mois. J'avais remarqué ce comportement, mais rien ne me dit s'il se produit encore chez pas mal de monde. À prendre avec des pincettes donc, je ne peux vérifier, vous êtres prévenus.
En effet, le compositing (fenêtres molles, etc) devient quasiment insupportable. Xorg sait très bien dessiner des images **directement** à l'écran, et je dis bien directement.
Il faut savoir comment marche un gestionnaire de compositing comme KWin. Quand une fenêtre est modifiée, elle l'est sur une partie invisible de l'écran (en fait, KWin affiche une grosse fenêtre qui recouvre toutes les autres, et dans laquelle il fait son petit mélange, c'est spécial à imaginer, mais il fait ça). Xorg en avertit KWin, qui recopie le contenu modifié de la fenêtre, met à jour une texture OpenGL, et dessine le résultat en utilisant OpenGL.
Bien, excellent :) . Non, c'est nul pour notre cas ! En effet, Qt envoie des images de fenêtre complètes, donc KWin, pour chaque modification mineure d'une fenêtre, doit récupérer une image colosalle (Xorg ne sait pas que seul le petit bouton en bas à droite a été modifié, il recoit une grosse image, lui). Il lui faut donc récupérer cette image, la convertir en texture OpenGL, l'envoyer à la carte graphique, qui fait sa popotte avec.
Résultat ? C'est insoutenablement lent. Autant c'est foudroyant comme le tonnerre sans compositing, autant le compositing tue tout. C'est malheureusement inacceptable d'utiliser Raster si on tient à ses effets glossy.
**NOTE** : Fin de la partie douteuse
Il y a également un autre inconvénient, qui sera surtout ressenti par ceux possédant une petite configuration (pas d'instructions multimédia, vieux processeur, etc), et utilisant beaucoup Konqueror.
Le scroll est une accélération typiquement gérée par XRender, qui fait tout faire par la carte graphique. Le scroll est donc fluide et ne consomme que peu de processeur. En utilisant Raster, il faut, malgré les optimisations de Qt (cache de la page web par exemple) renvoyer fréquemment une grosse image, et dessiner de nouveaux éléments. Ça occupe bien plus le processeur, et ralentit le compositing. Pour éviter les ennuis, désactivez «Défilement doux» dans les options de Konqueror, ou de tout navigateur basé sur Qt (Rekonq, Arora, Opera (ne l'oublions pas))
**Conclusion**
Avec KDE-Qt trunk (4.7), KDE trunk (4.4.50), et Qt compilé en utilisant le système graphique Raster, mon environnement KDE pète le feux comme jamais, et tout est aussi fluide que ce qu'on peut vouloir. Même des applications reconnues poussives comme Krita, KWord et Konqueror marchent sublimement bien. KDE 4.4 apportant de jolis effets dans Oxygen, avec des animations discrètes, je peux témoigner de la rapidité graphique du truc : avec XRender, impossible de distinger le doux fondu qui se produit quand on change d'onglet, alors qu'en Raster, le CPU n'est même pas utilisé à 100% et c'est fluide.
Si vous faites partie de ces gens qui n'ont connu qu'un KDE poussif et lent depuis la version 4.0, et qui utilisez soit de vieux pilotes Intel, le pilote libre ATI, ou le pilote propriétaire nVidia, testez un peu la simple manipulation du «-graphicssystem raster». C'est rapide, et c'est du pur bonheur.
Je n'aime pas devoir recompiler Qt. Si quelqu'un a une autre technique (fichier de configuration global à Qt contenant le réglage, que je n'ai pas trouvé dans qt4-config), qu'il ne se prive pas d'en parler ici.
Bon amusement avec un KDE léger (la manipulation libère d'ailleurs une centaine de Mio de RAM occupés par X quand des applis lourdes comme KDevelop sont lancées, car seule une Pixmap gérée par Qt est prise en RAM, et pas plein de caches XRender).