Pinaraf a écrit 3674 commentaires

C'est un dev de nVidia qui a introduit l'un des changements d'ABI dans X.org 7.1.

Le support d'X.org 7.0 c'est uniquement pour l'installeur : les dossiers ont changé, rien de grave quoi.
Pour X.org 7.1 par contre, c'est pour notamment supporter XVideo avec Composite activé.

Pour Looking Glass le problème est assez spécial.
En gros, lors de la transformation pixmap => texture, le chemin pris dans Java3D n'est pas optimal. Si on recevait immédiatement une texture, on y gagnerait énormément, mais en attendant on peut se contenter d'optimisations sur Java3D (et Looking Glass lui même, mais en plus faible proportion...)

Pour info, l'une des incompatibilités a été réalisée par un développeur de nVidia qui travaille sur le serveur X... (c'était pour implémenter le support de la redirection hors-écran dans XV)

Un truc qui n'est pas mis en avant : incompatibilité binaire avec les pilotes... Donc pas d'ATI ou nVidia propriétaire pour l'instant.

Tu peux détailler ton histoire de perfs ?
Tu confonds comme tout le monde perfs de la JVM et perfs de Swing ?

Le lien vers le site de Sun n'est pas le plus recommandé pour Looking Glass. Ce n'est pas mis à jour, l'aspect libre n'y apparaît pas...
Un meilleur lien : https://lg3d-core.dev.java.net/

Chipotage : Tanenbaum ne dit pas que les protections basées sur le langage sont révolutionnaires.
Il dit qu'elles sont les plus radicales.
Ce concept serait révolutionnaire s'il était neuf, or Tanenbaum parle d'un ordinateur "Burroughs B5000" qui utilisait déjà ce concept.

Sinon si tu veux découvrir encore un peu sans trop chambouler tout, tu peux aider à porter kde en Qt4, ou alors pour Phonon, en fait tu pourais faire beaucoup de choses avec ta perseverance je penses :)
Par exemple un correcteur de grammaire libre ça serait super...

Grâce à la séparation en plusieurs librairies de Qt4, ces bindings sont infiniment plus rapides à charger ! Avant avec Qt3, un from qt import ... prenait plusieurs secondes. C'était de mon point de vue un vrai problème (mes applications étant des inutilitaires qui doivent démarrer rapidement). Maintenant, on n'importe vraiment que ce que l'on veut.

Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
Bientôt, on pourra compiler du code Python...
http://codespeak.net/pypy/dist/pypy/doc/news.html
Y'a des trucs pour traduire du code python en C, mais aussi en assembleur, Java (!), Javascript (je suis perplexe, j'ai pas trop contrôlé...). J'ai aussi vu des dossiers smalltalk et llvm dans leur SVN...

il y a également Wine, qui a un des sources codes les plus bourrins que je connaisse (la compilation nécessite plus d'un giga d'espace disque)
Et OpenOffice reste avec son CVS... (plus de 5Go d'espace disque pour compiler, wine fait petit joueur à côté)

D'ailleurs, Git est utilisé par les devs de X.org aussi...

Comme XP ?

Ce n'est pas un voeu, c'est juste ce que j'ai cru comprendre en lisant la mailing list de Xorg...
http://lists.freedesktop.org/archives/xorg/2006-March/013579(...)

Compiz fait bon effet.
Xgl, on s'en fout réellement. Enfin, pour le grand public. Le grand public tu lui montres un serveur X, ça lui apporte strictement rien. C'est les applis qui tournent dessus qui sont intéressantes.
Aiglx sera intégré à X.org 7.1 à priori. Cela signifie que Compiz marchera sur un X.org normal, à condition que les pilotes le supporte... (Il me semble qu'il y a en plus une rupture d'ABI, donc tous les pilotes devront être mis à jour, donc ça donne une chance pour avoir des pilotes ATI et nVidia qui implémentent le texture_from_pixmap rapidement...)

Raté, cela n'a rien à voir avec Xgl lui même.
C'est parce que le serveur X avec Composite et un Composite manager ne demande pas, quand tu déplaces une fenêtre, de redessiner les fenêtres sous la fenêtre que tu viens de déplacer. Ceci est une source de consommation CPU importante, surtout avec des applis mal foutues ou des toolkits lourds.
Je pense que si tu utilises Xgl sans composite manager, tu auras les mêmes effets que dans un X.org "classique"...

Les GeForce 2 MX semblent être encore supportées... Cf le readme : ftp://download.nvidia.com/XFree86/Linux-x86/1.0-8756/README/(...)

Ben c'est la même extension, avec le même code peut-être, mais avec strictement la même syntaxe.

Ça n'empêche pas d'utiliser xglx hein.
Ça empêche par contre l'utilisation d'aiglx.
Et avant que ça ne trolle sur les pilotes nVidia, les raisons pour la non implémentation de l'extension : c'est qu'elle est pas stable. La spécification est en cours de rédaction/finalisation. Quand ça sera stable, ça sera implémenté normalement.

Y'en a un qui est merdique, et l'autre qui est ...
ben une merde quoi.


Zut, c'est pas une différence.
En fait, y'a windows messenger qui est fourni avec windows et qui utilise pas le protocole msn je crois, et msn messenger qui est pas fourni avec windows et qui utilise le protocole msn.

Je pense que certains geeks solitaires préfèreraient un autre genre de mannequin virtuel...

Encore raté.
Dans Xorg ce qui pêche c'est l'implémentation de XRender, pas l'implémentation de Composite. XRender est très lent, avec EXA ça va beaucoup mieux si les pilotes le supportent, sinon le RenderAccel des pilotes nvidia devrait être bien meilleur pour la prochaine version (au point d'être activé par défaut apparemment)

Ha oui y'a aussi ce changement, mais ce n'est pas lui qui change les traînées. L'OpenGL était d'ailleurs utilisable comme ça dans Java5, mais c'était pas par défaut (c'était pas prêt).
Ce qui change les traînées, c'est surtout l'ajout du double buffering récemment.

Je me suis amusé à tester quelques applications pour les traînées, pour que vous puissez comparer sur une machine sans avoir besoin de logiciels propriétaires. Le test est simple : ouvrir le dialogue à propos, et le déplacer partout pour voir si ça fait des traînées, et jusqu'à quel point.
1- KWord : pas de traînée (en tout cas j'en ai pas vu)
2- OpenOffice.org2 writer : traînées moyennes, pouvant aller jusqu'à saturer la fenêtre en allant vite
3- Firefox : traînées importantes, saturant facilement la fenêtre (thème Noia)
4- Synaptic (histoire d'avoir une appli Gtk sans thème) : traînées moyennes, sans saturation

Ma config : kubuntu dapper sur un Athlon XP 2000+, 512Mo de Ram, nVidia Geforce FX 5600