Journal En finir avec la lourdeur de KDE

Posté par steckdenis (site web personnel) le 28 janvier 2010 à 18:53.

Étiquettes :

jan.

2010

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 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, 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 (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).

# Et quand ça marche bien

Posté par Alex le 28 janvier 2010 à 19:06. Évalué à 5.

Quel est le point entre les kde qui tournent bien ?

Perso c'est le cas sur mes 2 machines, et j'en viens à supposer que c'est grace à mon gpu nvidia et ses drivers proprio, non ?
Comment sait-on quel backend on utilise ?
- [^] # Re: Et quand ça marche bien
  
  Posté par steckdenis (site web personnel) le 28 janvier 2010 à 19:12. Évalué à 5.
  
  Il me semble que là où ça tourne bien, c'est soit quand XRender n'est pas supporté (pilote VESA, et où on utilise alors Raster en fallback), soit quand tu as un bon pilote qui gère bien XRender et un processeur rapide.
  
  Mais c'est quasiment aléatoire, donc c'est mieux d'utiliser Raster en dur pour savoir que ça marchera chez tout le monde (pensée spéciale «créateur de distribution» ici :-) ).
  
  Pour savoir quel est le backend utilisé, je ne sais pas si c'est possible. Ça m'a d'ailleurs embêté lorsque j'ai ajouté la NOTE sur le test de Kwin, car je voyais que ça réagissait bien (donc comme si XRender était utilisé), donc j'ai du lancer une application en OpenGL (parce que c'est moche et lent, et que je vois que -graphicssystem est bien passé), puis à nouveau en Raster explicite pour voir que Raster s'est bien amélioré.
  
  Mais normalement, si c'est fluide tout le temps (sans saccades), alors c'est du raster.
  - [^] # Re: Et quand ça marche bien
    
    Posté par Alex le 28 janvier 2010 à 19:49. Évalué à 3.
    
    Mais normalement, si c'est fluide tout le temps (sans saccades), alors c'est du raster.
    
    Ce qui expliquerai pourquoi l'export de display que je fais de temps en temps sur une de mes installs (basé sur arch) rame.
    Par contre je testerai l'export de display de ma mandriva, pourtant il me semblait que mdv utilisait opengl par défaut.
  - [^] # Re: Et quand ça marche bien
    
    Posté par erable le 29 janvier 2010 à 00:18. Évalué à 1.
    
    Je voulais tester avec pyQt4 mais la variable contenant le mode utilisé n'est pas accessible car privée:
    void QApplication::setGraphicsSystem(const QString &system) { QApplicationPrivate::graphics_system_name = system; }
- [^] # Re: Et quand ça marche bien
  
  Posté par zebra3 le 28 janvier 2010 à 19:12. Évalué à 5.
  
  Quel est le point entre les kde qui tournent bien ?
  
  Celui-ci : .
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Et quand ça marche bien
  
  Posté par maxix le 28 janvier 2010 à 21:14. Évalué à 2.
  
  Je ne sais pas, mais avec kde4 et ses effets 3D ou sans, j'ai gagné une grosse réactivité des fenetres en passant d'une geforce 8400GS a une geforce 8800GTS. Meme driver, meme install.
# Ce serait fort quand même...

Posté par sirrus le 28 janvier 2010 à 19:14. Évalué à -10.

Attendre plus d'un an pour savoir pourquoi le bureau se traîne comme une marmotte subissant une accélération de 42G, c'est dire l'état de délabrement du projet kde.

Ah linux a dû attirer du monde en effet avec les effets tout jolis qui prennent trois secondes et font augmenter le bruit du ventilo...

Pour introduire cette partie, je vous conseille de jeter un oeil au journal Chromium est bien plus lent que FireFox (en passant au-dessus de tous les trolls bien entendu).

Tout à fait d'accord, halte aux trolls et posons les bonnes questions : tout cela est-il bien sérieux ? Si oui, vous pouvez me moinsser...
- [^] # Re: Ce serait fort quand même...
  
  Posté par imr le 28 janvier 2010 à 21:28. Évalué à 10.
  
  >Attendre plus d'un an pour savoir pourquoi le bureau se traîne comme une marmotte subissant une accélération de 42G, c'est dire l'état de délabrement du projet kde.
  
  Si c'était ça, ça serait rassurant, il suffirait de bruler KDE, mais le monsieur il parle de l'état du système graphique, de ses composants et des drivers graphiques proprio ET libres qui affectent KDE.
  Donc ça touche tous les desktop et toutes les applis graphiques, c'est juste que ça se voit plus quand un gros projet essaie de faire des choses qui sortent de l'ordinaire. Mais des lecteurs video qui ne marchent plus tout d'un coup et que je dois passer en X11 au lieu de XV parce que xorg ou les drivers intel ou xorg ont été "améliorés", je connais, et ça n'a rien à voir avec KDE.
# Que ton nom soit sanctifié

Posté par Anonyme le 28 janvier 2010 à 19:16. Évalué à 1.

Je comprends enfin pourquoi certains netbooks faisaient mieux tourner KDE4 que mon desktop.
J'attends quelques feedbacks sur Raster avant d'envisager une réinstallation...
- [^] # Re: Que ton nom soit sanctifié
  
  Posté par Sphax le 28 janvier 2010 à 20:11. Évalué à 2.
  
  Je vais recompiler mon Qt 4.6 avec Raster, pour tester globalement la différence. Mon KDE est globalement rapide, mais des fois ça rame sans que je sache vraiment pourquoi.
- [^] # Re: Que ton nom soit sanctifié
  
  Posté par imr le 28 janvier 2010 à 21:13. Évalué à 2.
  
  >J'attends quelques feedbacks sur Raster
  Je suis en kde 4.4 rc1, je désactive les effets parce que je m'en fiche, ça marche bien ici, j'ai un KDE4 réactif sur une machine de 2004 avec une nvidia.
  
  Si je fais konqueror en mode fichier avec raster, il se traine comme une loutre. J'ai l'impression qu'il rame quand il y a des aperçus.
  - [^] # Re: Que ton nom soit sanctifié
    
    Posté par bubar🦥 (Mastodon) le 02 février 2010 à 19:06. Évalué à 2.
    
    \o/ imr \o/
    as tu reçu un sac de maté ariégeois et bio l' an dernier ?
    - [^] # Re: Que ton nom soit sanctifié
      
      Posté par imr le 09 février 2010 à 04:10. Évalué à 2.
      
      non, jamais. Il a dû être mangé par les petits lapin.
# Personne?

Posté par JoeltheLion (site web personnel) le 28 janvier 2010 à 19:39. Évalué à 10.

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.

Personne n'utilise le protocole X à travers le réseau? Si, moi! Et je suis sûr de ne pas être le seul à profiter de ssh -X...
- [^] # Re: Personne?
  
  Posté par khivapia le 28 janvier 2010 à 20:06. Évalué à 10.
  
  Je pertinente. C'est souvent bien pratique...
  - [^] # Re: Personne?
    
    Posté par totof2000 le 29 janvier 2010 à 00:00. Évalué à 2.
    
    ... surtout quand on a des applis serveurs à configurer et que MS Windows Redhat ne fournit que des interfaces graphiques pour toucher la cnf du bouzin.
    - [^] # Re: Personne?
      
      Posté par zebra3 le 30 janvier 2010 à 04:04. Évalué à 5.
      
      Euh c'est quoi la CNF ?
      
      Je bosse avec du Red Hat tous les jours, et pour chaque interface graphique, il y a soit une interface équivalent en ncurse, soit c'est bêtement des fichiers de conf. Alors j'aimerai bien savoir quelle fonctionnalité nécessite une GUI pour être configurée.
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: Personne?
        
        Posté par BAud (site web personnel) le 30 janvier 2010 à 16:14. Évalué à 1.
        
        Euh c'est quoi la CNF ?
        
        bin, au hasard, la conf' non ?
      - [^] # Re: Personne?
        
        Posté par totof2000 le 09 février 2010 à 17:09. Évalué à 2.
        
        T'as bossé avec Redhat Cluster ?
  - [^] # Re: Personne?
    
    Posté par B16F4RV4RD1N le 29 janvier 2010 à 00:28. Évalué à 3.
    
    surtout pour faire tourner KDE au complet !
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: Personne?
  
  Posté par zerkman (site web personnel) le 29 janvier 2010 à 07:51. Évalué à 9.
  
  et avec ssh -X -C tu as la compression, bien pratique quand la machine est un peu éloignée.
  - [^] # Re: Personne?
    
    Posté par zebra3 le 30 janvier 2010 à 04:06. Évalué à 4.
    
    Plus simple : mettre « ForwardX11 yes » et « Compression yes » dans ~/.ssh/config .
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Personne?
    
    Posté par benoar le 30 janvier 2010 à 18:24. Évalué à 8.
    
    Et ssh -X est connu pour avoir des failles depuis longtemps, maintenant c'est ssh -Y.
# Et GNOME?

Posté par devnewton 🍺 (site web personnel) le 28 janvier 2010 à 19:40. Évalué à 7.

GTK a une recette magique par rapport à Qt?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Et GNOME?
  
  Posté par sirrus le 28 janvier 2010 à 19:50. Évalué à 3.
  
  Oui, son design est pourri à la base...
- [^] # Re: Et GNOME?
  
  Posté par steckdenis (site web personnel) le 28 janvier 2010 à 20:13. Évalué à 0.
  
  Je ne suis absolument pas certain de ce que j'avance, mais il me semble que GTK étant un peu plus ancien et un peu plus sobre, il utilise la XLib directement pour le dessin, donc pas XRender, ni un raster.
  
  Ça évite les problèmes de Raster, ça n'est pas trop lent quand XRender traîne, mais c'est relativement lent en général (même si c'est léger, les UI GTK étant relativement simple et les thèmes épurés, on ne le remarque pas trop. Certaines personnes se plaignent de ça en parlant d'Evolution qui traîne à se redessiner).
  - [^] # Re: Et GNOME?
    
    Posté par ecyrbe le 28 janvier 2010 à 21:22. Évalué à 10.
    
    Et bien tu as tout faux...
    Gtk donc Gnome utilise cairo comme backend graphique. Dans cairo il y a aussi un mode raster, opengl (en cours de refonte actuellement), xlib, xcb, svg, pdf, ps, etc... par défaut c'est le mode xlib qui est employé et il utilise quand celà est disponible XRender...
    - [^] # Re: Et GNOME?
      
      Posté par Maclag le 29 janvier 2010 à 02:49. Évalué à 5.
      
      En même temps c'est rassurant, parce que pendant un moment j'ai cru qu'on allait avoir comme résumé:
      
      -KDE4 peut être rapide, mais faut recompiler plein de trucs et avoir des limitations
      -sinon KDE4 peut être lent, mais sans les limitations
      
      - Et GTK est presque aussi rapide que KDE4 rapide mais sans limitation parce qu'il utilise des technologies obsolètes pour faire exactement la même chose.
      
      Cherchez l'erreur...
- [^] # Re: Et GNOME?
  
  Posté par gnumdk (site web personnel) le 28 janvier 2010 à 21:47. Évalué à -1.
  
  Une recette magique pour nous cacher à quel point il rame?
  
  Oui, compiz & co...
  
  Franchement, c'est vrai que des que l'on peut activer les effets graphiques sous Gnome, ca dernier est véloce...
  
  Sans composite? Ben, il est toujours véloce, par contre GTK se traine comme une grosse bouse pour redessiner les fenêtres... Qt lui s'en sort beaucoup mieux même si ce n'est pas parfait.
  - [^] # Re: Et GNOME?
    
    Posté par Zarmakuizz (site web personnel) le 28 janvier 2010 à 22:48. Évalué à 3.
    
    Franchement, c'est vrai que des que l'on peut activer les effets graphiques sous Gnome, ca dernier est véloce...
    
    J'avoue avoir été étonné de voir chez un ami que, quand il active le benchmark de Compiz, son bureau est soudainement plus rapide. (Pas d'ironie dans ce message)
    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
    - [^] # Re: Et GNOME?
      
      Posté par yellowiscool le 28 janvier 2010 à 23:51. Évalué à 2.
      
      Dans les réglages de compiz, on peut régler la fréquence de mise à jour. Peut-être que le benchmark désactive cette limitation volontaire, et donne un résultat plus fluide.
      Envoyé depuis mon lapin.
      - [^] # Re: Et GNOME?
        
        Posté par Damien Thébault le 29 janvier 2010 à 11:05. Évalué à 7.
        
        De base, compiz utilise la VSYNC pour éviter tout effet de tearing.
        Cependant, utiliser la VSYNC limite le framerate à un diviseur entier de la fréquence de rafraichissement de l'écran.
        Par exemple, pour un écran 60Hz, le temps entre 2 images avec la VSYNC activée est de 1/60s, 1/30s, 1/15s, etc...
        Si jamais l'affichage d'une image "rate" le VSYNC, il va falloir attendre le prochain. Donc typiquement, si le FPS de compiz est un tout petit peut inférieur à 60fps, on va tout de suite descendre à 30, ce qui se voit.
        
        Le deuxième point, c'est la détection de la vitesse de rafraichissement. Compiz utilise xrandr pour détecter la fréquence de rafraichissement de l'écran. Sur certains drivers nvidia, la fréquence de xrandr n'est pas la fréquence réelle de l'écran, mais est une clé utilisée pour pouvoir faire la disctinction entre les modes quand on utilise twinview.
        (à savoir, 2 écran en 1280x1024, une config avec l'écran A à gauche et le B à droite et une config avec l'inverse auront la même résolution dans xrandr mais une fréquence de rafraichissement différente pour permettre au driver de choisir la bonne configuration).
        Du coup, Compiz n'obtient pas la bonne fréquence de rafraichissement (typiquement, ça commence à 60 et décroit), donc utiliser un framerate inférieur à 60 FPS, donc tombe à 30 FPS avec la VSYNC activée.
        
        Au final, la chose la plus simple est de désactiver la VSYNC dans compiz, on peut alors voir parfois des effets de tearing, mais au moins ça va vite.
        Sinon la solution compliquée c'est de vérifier que la carte graphique arrive sans problème à afficher plus que ce qu'il y a besoin avec la VSYNC activée, avec le mode benchmark de Compiz et de vérifier que la VSYNC est bien détectée, et la forcer à la main si besoin.
  - [^] # Re: Et GNOME?
    
    Posté par Dup (site web personnel) le 28 janvier 2010 à 23:46. Évalué à 1.
    
    il me semble qu'il y a un patch quelque part qui corrige ce mauvais point de gtk mais pas encore dans les sourcesofficielles;
    - [^] # Re: Et GNOME?
      
      Posté par ecyrbe le 29 janvier 2010 à 11:52. Évalué à 2.
      
      Si c'est déjà implémenté dans Gtk+ 2.18 avec Client Side Windows... news que j'avais rapporté il y a quelques temps
      - [^] # Re: Et GNOME?
        
        Posté par Dup (site web personnel) le 29 janvier 2010 à 14:08. Évalué à 2.
        
        Autant pour moi alors ;)
        
        [^] # Re: Et GNOME?
        
        Posté par Anonyme le 29 janvier 2010 à 19:06. Évalué à -1.
        
        s/Autant/Au temps/
      - [^] # Re: Et GNOME?
        
        Posté par Vivi (site web personnel) le 29 janvier 2010 à 18:25. Évalué à 3.
        
        ici pour ceux que ça intéresse : http://linuxfr.org/~moreira/28538.html
# Fichier de config

Posté par HoloAddict (site web personnel) le 28 janvier 2010 à 19:53. Évalué à 3.

J'était déjà plus ou moins au courant de cette problématique, mais moi ce qui m'embête le plus c'est l'activation du mode raster ou opengl de Qt. Comme tu l'as préciser toi-même, il faut recompiler Qt !

Je sais pas vous, mais moi j'ai un gestionnaire de paquet qui me l'a installé, et si je recompile Qt et supprime l'ancien, il va me virer tout KDE. Et j'ai vraiment pas envie d'avoir recours à de grosse bidouille. J'ai également envie qu'il se mette à jour tout seul.

Je suis persuadé qu'un simple fichier de configuration globale serait possible, ou une option dans qtconfig ou le panneau KDE. Mais malgré toutes mes recherches, je ne trouve rien. Qu'est ce qui empêche ceci ?
- [^] # Re: Fichier de config
  
  Posté par gnumdk (site web personnel) le 28 janvier 2010 à 21:50. Évalué à 4.
  
  Faut pas pousser non plus, c'est quoi ta distribution?
  
  Tu prend la paquet source, tu rajoutes l'option pour le raster...
  
  Tu augmentes le numéro de version et c'est ok... Ca va pas te virer Kde... Ou alors change de distrib.
  - [^] # Re: Fichier de config
    
    Posté par HoloAddict (site web personnel) le 30 janvier 2010 à 21:30. Évalué à 1.
    
    Je suis sous Arch, et je suis persuadé (même si je ne sais pas vraiment comment) que je peux récupérer le PKGBUILD et y ajouter l'option du configure.
    
    MAIS augmenter le numéro de version, tu trouves pas c'est horriblement moche ? Exemple : KDE 4.4 sors, et demande Qt4.6. Moi j'ai compiler Qt4.5 avec mon option et augmenter le numéro en Qt4.6 ou Qt5 pour être tranquil, et bien après une simple mise à jour de KDE mon bureau ne marchera plus du tout, car il n'aura pas la lib nécessaire.
    
    Après si par augmenter le numéro tu entends Qt4.5.4, ou encore Qt4.5.3-5, la mise à jour à la prochaine version de maintenance de Qt4.5 ou à la version 4.6 et je retourne à un bureau sans raster.
    
    Bref, loin d'être une solution optimale selon moi. Un simple fichier configuration serait tellement plus efficace (et simple) !
    
    PS: après je peux ignorer les updates de Qt et tous les logiciels qui en dépendent, c'est vrai. C'est juste grandement dommage...
- [^] # Re: Fichier de config
  
  Posté par Philippe F (site web personnel) le 29 janvier 2010 à 11:39. Évalué à 3.
  
  Je suis d'accord. Je trouve ça notamment bizarre que il soit possible d'utiliser le mode raster en passant un argument en ligne de commande, mais que pour l'utiliser par défaut, il faille recompiler Qt.
  
  D'autant plus qu'il me semble que Qt a maintenant un petit fichier de config dans le répertoire utilisateur.
# Complément d'infos

Posté par Olivier Serve (site web personnel) le 28 janvier 2010 à 20:05. Évalué à 7.

Explications complémentaires de Zack Rusin : http://zrusin.blogspot.com/2009/08/2d-in-kde.html
Je n'ai pas tout relu, mais c'était instructif.

NB: Zack Ruzin fait partie de l'équipe qui développe Gallium3D et a participé au développement des moteurs graphiques de Qt4.
# Nostalgie...

Posté par Beurt le 28 janvier 2010 à 21:54. Évalué à 4.

KDE 3.5 c'était si bien... On ne se posait ces questions...

Sur mon laptop j'utilise encore une vieille Mandriva (2009.0) juste pour profiter de KDE 3.5 un peu plus longtemps (pourtant il y a aussi dessus une 2010.0 avec un KDE 4.3 assez honnête... Mais ça vaut pas ce bon vieux 3.5...)
# merci pour ce journal

Posté par ZeroHeure le 29 janvier 2010 à 11:27. Évalué à 5.

Excellent journal, fais vite une dépêche!
Et merci pour toutes ces précieuses infos.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
- [^] # Re: merci pour ce journal
  
  Posté par steckdenis (site web personnel) le 29 janvier 2010 à 19:48. Évalué à 1.
  
  Je veux bien que les administrateurs passent ce journal en dépêche, s'ils le jugent utile (après tout, c'est une simple astuce que j'ai développée pour pouvoir la mettre en journal, pour que plus de monde la voient et arrêtent de troller sur la lourdeur de KDE).
  - [^] # Re: merci pour ce journal
    
    Posté par bubar🦥 (Mastodon) le 02 février 2010 à 16:02. Évalué à 5.
    
    Troller ? pas toujours. Souvent il s'agit de simples constats d'utilisateurs, n'ayant nullement l'intention de troller.
    Merci pour ton journal clair, et apportant des précisions.
    
    Mais vraiment il ne s'agit pas de troller, il s'agit certainement souvent de simples constats sans argumentaires techniques car dans l'impossibilité d'en faire. Un exemple ? autour de moi, dans ma famille innée proche, il y avait 5 postes Linux : 5 bureaux kde 3.x.
    Kde 4 est arrivé (j'ai patentier jusqu' à cet autonomne pour leur faire essayer), arrivé chez eux : résultat ? c'est lourd, réellement lourd. Pour des utilisateurs venant de kde3 c'est incompréhensible : "c'est lent, et parfois j'ai 'ça' qui plante. C'est vraiment trop lent". Voilà c'est tout, pas plus, mais pas moins...
    
    Résultat ? aujourdhui : 5 bureaux Gnome. Et même les agés ont préférés faire l'effort d'avoir un nouveau menu, un nouveau bureau, un nouveau navigateur de fichiers, plutot que de supporter kde.
    
    Je suis le premier désolé.
    C'était juste pour dire qu'il ne s'agit pas toujours de troll. Mais simplement quant un utilisateur voit le même ordinateur "planter" et "ramer" souvent, il ne comprends pas. Et moi avec lui.
  - [^] # Re: merci pour ce journal
    
    Posté par reno le 10 février 2010 à 11:54. Évalué à 2.
    
    Ce que je trouves amusant, c'est que le journal explique un problème qui a une répercussion immédiate chez les utilisateurs (ça rame) et que s'ils s'en plaignent tu appelle ça troller??
    
    D'autant plus que Qt et KDE sont loin d'être innocent dans l'affaire: ils ont décidés d'utiliser un nouveau système graphique qui ne marche pas bien encore dans beaucoup de cas (ok ça ce n'est pas de leur faute mais c'était prévisible) mais sans permettre aux utilisateurs d'utiliser simplement une solution de repli (raster) qui résoudrait cette lenteurs dans une majorité des cas (gros CPU + utilisation locale + effets désactivé), si le journal est correcte et la oui c'est de leur faute!
# changer de theme

Posté par ZeroHeure le 29 janvier 2010 à 11:52. Évalué à 3.

Si j'ai bien compris, désactiver les effets et changer de thème graphique devrait accélérer KDE (ça ne fait pas de différence sur mon poste)?
Et si le thème graphique est indirectement responsable de la lenteur, on pourrait en créer un sollicitant moins XRender ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
- [^] # Re: changer de theme
  
  Posté par Frédéric COIFFIER le 29 janvier 2010 à 12:53. Évalué à 4.
  
  Je confirme pour le thème graphique.
  
  Étant la plupart du temps connecté à distance (avec NXClient http://nomachine.com/ ), l'utilisation du mode raster est inenvisageable (pour les raisons décrites dans le journal).
  
  La première fois que je suis passé sous KDE4, j'ai ressenti une très grosse lenteur par rapport à KDE 3.5 en connexion à distance.
  Puis, je me suis aperçu qu'en choisissant le style "Cleanlooks" à la place "d'Oxygen", je retrouvais quasiment la vitesse de KDE3 (mais aussi le look).
  
  Pour compléter le journal, j'ajoute que Qt 4.6 a pas mal amélioré les performances du Qt (à priori, parce que Nokia a fait un gros effort d'optimisation pour l'embarqué).
  
  Donc, si vous ne souhaitez rien recompiler, patientez pour KDE 4.4 (qui lui améliore la vitesse de démarrage) qui arrivera avec Qt 4.6 dans les distributions et changez le style pour "Cleanlooks".
# pilote libre ati et Qt4

Posté par fusible le 29 janvier 2010 à 12:21. Évalué à 4.

Je dois avoir de la chance, n'ayant jamais spécialement eu a me plaindre de la vitesse d'affichage des applies quel que soit le toolkit graphique.

J'ai deux ordis : un portable avec une GeForce Go 6150 (pilote libre nouveau) et une tour avec une Radeon X1600 (pilote libre radeon). Dans les deux cas, le changement de bureau / d'onglets / … est toujours immédiat. Ok, tant mieux pour ma gueule.

Par contre, ma radeon avec son pilote libre m'a longtemps cassé les roubs avec des ralentissement incompréhensibles. Pas dans l'affichage des fenêtres mais lors du survol d'une fenêtre Qt4 (pas KDE puisque ça le faisait aussi avec smplayer par ex.). Donc lorsque le pointeur de la souris survolait certains éléments de la fenêtre (sans qu'il y ait spécialement d'effet graphique associé) le processus d'X passait à 100 % et freeze de tout l'affichage pendant 1 seconde. De quoi maudire Murphy quand à coté un pilote développé sans spécifications sans sort tellement bien que je peus même activer certains effets de compositing [1] sans affoler le processeur.

Aujourd'hui, après avoir essayé un peu tout et n'importe quoi, j'ai fini par trouver la solution : activer l'option AccelDFS (man radeon) dans xorg.conf et tout rentre dans l'ordre. \o/

[1] l'ombrage sous la fenêtre c'est super pour distinguer les fenêtres quand on ne supporte pas le gâchis de pixels et qu'on dégage la barre de titre et la bordure qui va avec. :)
# Conclusion

Posté par Guillaume Knispel le 30 janvier 2010 à 16:07. Évalué à 8.

X-Window ne vaut plus un clou depuis que les widgets sont jolis.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.