Juste pour rectifier certains trucs/apporter des détails:
[mode pavé=on]
Brunni (./89) :
Sasume (./69) :
Brunni (./63) :
Par contre la composition c'est pratique, quand t'es habitué à avoir la synchro verticale pour toutes tes fenêtres c'est difficile de revenir en arrière 
De quoi parles-tu, plus précisément ?
De Compiz, Aero, etc.Ca passe par l'accélération 3D des cartes graphiques au lieu de taper en soft dans le framebuffer. Grâce à ça on peut s'offrir plein de trucs sans charger le CPU, notamment niveau redimensionnement des images (pour les autres DPI), dessin vectoriel, lissage de texte sous Mac, effets de transparence, d'ombre, fade, etc.
Techniquement c'est pas vrai... Tu n'as jamais entendu parler d'accélération 2D ? Avec GDI comme avec X.Org (et XFree auparavant) c'est utilisé depuis presque toujours (Enfin y'a forcément un moment où ça a réellement commencé mais je saurais aps te dire quand exactement... disons Windows 95 ?
). Si tu devais t'en passer sur un système tu t'en arracherais presque les cheuveux aujourd'hui ^^ (Teste un Windows/Linux en mode VGA tu comprendras vite)
Paradoxalement, on a perdu tout ça sur Vista quand Aero a fait son apparition. On a gagné de l'accélération 3D pour le rendu final des fenêtres mais on a perdu l'accélération 2D sur le contenu, c'est pour ça que beaucoup de monde s'est plain de Vista, et probablement pour ça qu'on la retrouvera sous Windows 7.
Et parmi ces avantages tu as le double buffering, comme dans les jeux. Comme ça il n'y a plus de "coupures" ou de trainées typiques quand on bouge une fenêtre. Il y a aussi moins de clignotements lors des mises à jour de champs (en théorie il devrait même ne plus y en avoir, mais je sais pas pourquoi, ça dépend des applis, peut être qu'il faut des nouvelles APIs).
Pas vraiment de gain pour le double-buffering car les applications intègrent pour la majorité déjà leur système de double buffering, ça serait plutôt une perte de mon point de vue... Après si il reste des clignottements dans certaines applications c'est juste que le code est crade (et de ce point de vue ça pourrait même venir directement de GDI ça ne me choquerait pas... Le système de dessin sous Windows a tendance à devenir de plus en plus tordu)
Par contre niveau RAM c'est l'horreur parce que t'as 2 textures RGBA 32 bits par fenêtre, donc une fenêtre en 1920x1200 (le desktop par exemple) prend pas moins de 18 Mo... (sauf pour ceux qui ont de la VRAM dédiée)
C'est tout à fait normal et pas vraiment horrible
Une copie "sûre" en mémoire système, et une copie "non sûre" en mémoire vidéo pour l'affichage rapide. Sur un système conçu normalement c'est ce qu'il y a de mieux, même si tu dois avoir un léger surcout pour la synchronisation copie1 -> copie2 à chaque fois. Après forcément si tu as un chipset graphique tu es tenté de considérer que la mémoire est utilisée deux fois parce que tu vois la mémoire allouée au chipset graphique comme de la mémoire système, mais ce n'est plus exactement le cas. (Sinon pour les 18 Mo, si jamais DWM utilise un depth buffer ça peut monter jusque dans les 26-27 Mo
)
Brunni (./98) :
Flanker (./94) :
À ce sujet, il me semble que Compiz transformait chaque fenêtre en une seule texture et appliquait les effets à la texture globale, alors qu'Aero (tout comme Aqua) permettent de faire des animations 3D à l'intérieur de la fenêtre (typiquement Coverflow). C'est encore d'actualité ?
Non, Aqua je sais pas, mais Aero & Compiz font le rendu sur une texture (généralement en soft, sauf si ton prog utilise OpenGL, et même dans ces cas je pense que ce n'est pas direct: il y a une copie du drawbuffer qui se fait sur la texture).
Plus exactement:
Pour les applications utilisant l'ancien API (donc plus de 99% quoi) ça fonctionne comme avec compiz +/-. On dessine dans un DC qui représente un
Bitmap hors écran, et on le transfère dans une
Texture en mémoire vidéo pour l'affichage si nécéssaire (essentiellement, si l'application est visible quoi).
Pour les applications utilisant un API de rendu graphique matériel (DirectDraw/DirectX/OpenGL quoi), rien n'a changé par rapport à précédemment: En mode fenêtré, le rendu est effectué dans une
Texture/
Back Buffer et DirectX9Ex/DirectX10 grâce au support des textures partagées, permettent à DWM d'accéder directement à la texture pour l'afficher comme contenu de la fenêtre (la seule différence est que ce n'est plus vraiment un simple blitting maintenant); En mode plein écran, DWM cède entièrement l'accès au matériel à l'application, du coup ton backbuffer est directement envoyé à l'écran sans autre détour. (ça veut également dire que Aero Glass est désactivé pendant ce temps... D'ailleurs il peut-être intéressant de le désactiver totalement pour les jeux où tu fais beaucoup de retours windows, ça évite les délai de redémarrage/arrêt de aero à chaque fois)
Pour les applications utilisant le nouvel API (WPF): L'interaction entre WPF et DWM (via milcore) va bien au dela d'un simple rendu sur texture, et sauf erreur de ma part, DWM doit normalement avoir entièrement accès à l'arbre de rendu sous-jacent... Enfin il ne me semble pas que Flanker dise une bêtise
La différence c'est que Compiz* fait du single buffering (1 texture par fenêtre) car les linuxiens sont proches de leur RAM, alors que Windows en utilise 2 quand l'application est active, 1 quand elle est minimisée.
Sauf erreur de ma part, de base compiz utilise aussi 2 textures, et dernièrement c'était une partie essentielle du travail que de faire en sorte qu'il n'y en ait plus qu'une (car il n'y a pas de mystère, le support graphique sous linux est merdique et il n'y a absolument aucune interface de vraiment standardisée... Enfin c'est standardisé au jour le jour quoi :/)... Donc le résultat ici dépend essentiellement du driver utilisé (je dois avouer que ça fait quelque mois que j'ai pas suivi je sais plus où ça en est des nouveaux gestionnaires de mémoire pour X enfin bon). Egalement Compiz galèrait (même problème / mêmes raisons) à faire la redirection vers une texture pour les applications Graphiques (OpenGL donc vu qu'il n'y a que ça), je ne sais pas non plus où ça en est...
[/mode pavé=off]
Je ne vois pas pourquoi ça serait féminin.
). Si tu devais t'en passer sur un système tu t'en arracherais presque les cheuveux aujourd'hui ^^ (Teste un Windows/Linux en mode VGA tu comprendras vite)
Une copie "sûre" en mémoire système, et une copie "non sûre" en mémoire vidéo pour l'affichage rapide. Sur un système conçu normalement c'est ce qu'il y a de mieux, même si tu dois avoir un léger surcout pour la synchronisation copie1 -> copie2 à chaque fois. Après forcément si tu as un chipset graphique tu es tenté de considérer que la mémoire est utilisée deux fois parce que tu vois la mémoire allouée au chipset graphique comme de la mémoire système, mais ce n'est plus exactement le cas. (Sinon pour les 18 Mo, si jamais DWM utilise un depth buffer ça peut monter jusque dans les 26-27 Mo 
)
Les problèmes que tu as rencontrés ont été corrigés. Et si les autres distributions avec KDE 4.2 sont aussi fiables, c'est aussi en grande partie grâce à nous. Il faut bien que quelqu'un propose la nouvelle release en premier, sinon il n'y aura jamais de retours.
