Pinaraf a écrit 3682 commentaires

Vous aurez corrigé : c'est jeudi 15 et pas jeudi 14...

On en a un, mais on n'a pas un truc dédié à l'évènement.

Le problème c'est qu'ils demandent un site web parlant de l'évènement...

Le problème c'est qu'ils demandent un site web parlant de l'évènement...

Ok, j'ai eu le même problème.
Je suppose que t'as X.org 7.0 sur ta machine. En gros, c'est l'installeur qui ne remplace pas certains fichiers de DRI. Donc il faut supprimer à la main /usr/lib/dri/atiogl_a_dri.so et /usr/lib/dri/fglrx_dri.so
Ensuite, tu lances l'installeur et ça roule.
Sinon, si t'as pas X.org 7.0 mais 6.8, il faut supprimer ces deux fichiers quelque part dans un sous-dossier de /usr/X11R6.
Si ça marche pas, tu peux me contacter sur Jabber : pinaraf@jabber.fr

Pour commander des CDs de kUbuntu : https://shipit.kubuntu.com/

Je cite : "Since we're changing the ABI/API for 7.1, I figured now is a good time to add redirected XV support to the DDX."
http://lists.freedesktop.org/archives/xorg/2006-February/013(...)
Ce n'est pas du tout un règlement de compte. C'est juste un développeur de chez nVidia que vu qu'il y avait déjà un changement d'API/ABI, autant en faire un autre comme ça ça évitera d'avoir à recasser ultérieurement.

Quels messages ? J'en ai eu aussi !

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"...