Ma vie rêvée

Un superbe court métrage d'animation réalisé par des étudiants et disponible sur le site de l'école de l'image Gobelins. Je vous conseille également de regarder les autres courts métrages ; ils sont tous bons. Notamment Motus et Bouche Cousue pour sa chute.

Vu sur le blog de Bertrand Lemaire (Le Monde Informatique), la parution, aujourd'hui, du décret pénal de la loi DADVSI.

Pour résumer, si je lis bien le texte, il devient illégal et puni d'une amende de classe IV (750€ maximum) le fait de détenir ou utiliser un logiciel de contournement des mesures techniques de protection. En substance, je n'ai plus le droit d'écouter certains de mes CD sur mon baladeur ou sur mon ordinateur. Où encore de lire mes DVD sur ma machine sous GNU/linux (encore que je ne suis pas sur que CSS soit encore considéré un moyen efficace).

Une bonne année qui s'annonce.

Vu sur Format Ouverts, une phrase qui résume bien ma pensée sur les messageries instantanées (l'article parle de la compatibilité MSN/Yahoo) :

il est tout de même incroyable de penser que pour échanger ou discuter avec les autres, ces autres doivent avoir l'un des 2 logiciels et uniquement ceux-là ! A contrario pour le fax, le courriel ou le téléphone, les appareils de n'importe quelle marque permettent de communiquer.

Il y a quelques temps, j'avais palié au manque de flash sur ma machine en utilisant une combinaison de 3 choses intéressantes : DownloadWith, youtube-dl et mplayer. Tout cela est explicité dans 2 billets :

• Comment j'ai vaincu Flash et Youtube
• Flash et Youtube (bis)

Ça marche bien mais ça manquait un poil de finition.

Les choses en serait resté là si je n'avais pas, par hasard, découvert récemment un billet de Michael Sheldon qui présente un script greasemonkey qui permet de s'affranchir totalement de flash pour lire une video sur youtube. En pratique, ce script remplace l'applet flash par un appel direct à la video qui peut alors être lu par un plugin de lecture multimedia (mplayerplug-in, ou vlc plugin par exemple) ; le résultat est alors totalement transparent.

Comme je n'utilise pas firefox mais seamonkey, je ne peux pas installer l'extension greasemonkey, j'ai donc modifié légèrement le script (il est sous licence GNU GPL) pour pouvoir l'utiliser comme bookmarklet. C'est à dire que j'ai créé un marque page qui contient comme adresse le contenu du script. Il me suffit alors de l'éxécuter sur une page youtube pour voir apparaitre la video :).

Le script modifié est disponible à l'adresse suivante :http://mjules.free.fr/divers/flvplayer.user.bookmarklet.js ; pour l'utiliser, copier son contenu dans le champ adresse d'un marque-page. Ensuite, il suffit de charger le marque-page sur une page youtube.

MAJ :Il semblerait que ce script ne fonctionne qu'avec gecko 1.8.1, c'est à dire Firefox 2 ou seamonkey 1.1beta

...récupère de sa difficile escapade dans le salon.

Plan général

1. Les bases, le rendu 2D
2. Le rendu 3D direct
3. Le rendu 3D indirect
4. Composite et XGL
5. AIGLX
6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Qu'est ce qu'il reste à dire ?

Plus grand chose en fait, nous avons vu à peu près les grands principes de fonctionnement de X11 et des dernières technologies développées autour. Il y a seulement 1 an, beaucoup de monde râlait et pestait contre Xorg et sa gestion antédiluvienne des fenêtres par rapport à des OS comme MacOS X ou même XP.
1 an plus tard, on peut dire sans trop de complexe que La couche graphique X11 n'a pas grand chose a envier aux derniers développements des OS propriétaires. Il reste encore beaucoup à faire et à inventer pour amener le plein potentiel de ces technologies mais elles sont là et elles marchent.

Il reste néanmoins quelques problèmes à régler :

• Pour rester sur le fonctionnement de X11, à l'exception d'XGL qui ne remporte pas les suffrages, beaucoup de choses sont encore gérées par la partie 2D de la carte graphique avec les limitations que l'on connait. Cela devrait néanmoins se régler grace à des initiatives comme Glucose qui permet d'accélérer le rendu grâce à la partie 3D (il utilise une partie du code de XGL pour modifier le serveur X existant).
• Plus généralement, et c'est je pense, le plus gros problème avec les nouvelles technologies de X11, tout cela repose sur l'utilisation intensive de la partie 3D. Ce qui confine de fait à l'utilisation des pilotes propriétaires d'ATI ou de NVIDIA avec tout les problèmes que cela pose (obsolescence obligatoire du matériel, failles de sécurité masquées, impossibilité d'évolution tant que le pilote n'est pas mis à jour au bon vouloir de la société, etc). Néanmoins, des solutions existent ou se rapprochent même si elles ne sont pas parfaites : les pilotes Intel (2D et 3D, puces intégrées) sont libres et même si les cartes ne sont pas des foudres de guerres, elles sont suffisantes pour beaucoup ; les cartes ATI jusqu'au x800 disposent d'un pilote 3D libre qui marche pas trop mal et ne devraient plus trop tarder à être disponible par défaut (les cartes < radeon 9200 en on déjà un); l'espoir pour les cartes nvidia repose sur le projet Nouveau qui avance relativement bien ; à plus long terme, c'est le projet Opengraphics qui vise à développer une carte graphique complètement ouverte.

Le mot de la fin

J'espère que ça vous (les lecteurs) a plus, que ça vous a un peu éclairé et que je n'ai pas dit trop de bêtises (je ne pense pas mais sait on jamais).
Quant à moi, j'ai bien aimé Inkscape, c'est vraiment sympa à utiliser, surtout la dernière version que je trouve nettement plus ergonomique que la précédente.

Bibliographie

• L'annonce de Glucose
• La page du DRI (le projet qui s'occupe des pilotes 3D de X)
• La page du projet Nouveau
• Le site d'Opengraphics
• Linux in a binary world, un essai d'un développeur du noyau Linux sur les conséquences des pilotes propriétaires

Plan général

1. Les bases, le rendu 2D
2. Le rendu 3D direct
3. Le rendu 3D indirect
4. Composite et XGL
5. AIGLX
6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

Où en est t'on ?

Dans les billets précédents, on a vu comment Xorg se débrouillait pour afficher des choses sur l'écran en 2D et en 3D. Ça fonctionne très bien mais ce mode de fonctionnement comporte des limitations qui rendent difficile l'évolution de l'affichage. En particulier, avec ce mode de fonctionnement, il est très complexe de faire des choses comme des ombres derrières les fenêtres, ou tout bonnement des fenêtres transparentes. C'est pourquoi le protocole X11 a été encore étendu avec l'extension Composite. Celle-ci va permettre de modifier le comportement du rendu. En effet, au lieu que le serveur envoie directement les informations sur chaque fenêtre à la carte graphique ; celles-ci sont envoyées dans un espace de la mémoire où elles peuvent être ensuite manipulées par un gestionnaire de composition avant que le résultat soit rendu par la carte graphique.
L'énorme avantage, c'est qu'avec cette méthode, il devient très simple de faire, par exemple, une fenêtre réellement transparente. Le gestionnaire de composition possédant toutes les infos pour celà (il sait exactement quelle fenêtre est au dessus de quelle autres etc).
L'énorme inconvénient, c'est que ça nécessite beaucoup de puissance graphique et donc, pour pouvoir faire ça sans que l'affichage rame atrocement, il faut de l'accélération par la carte graphique.

Cette accélération est disponible avec la partie 2D de la carte via les extensions XAA ou plus récemment EXA. Néanmoins, l'accélération 2D pose quelques problèmes qui rendent son utilisation peu intéressante :

• XAA était difficile à implémenter dans les pilotes et n'accélérait que peu de fonctions 2D
• EXA est plus simple à implémenter mais il ne l'est toujours pas dans un grand nombre de pilotes
• la partie 2D des cartes graphiques se réduit de plus en plus au profit de la partie 3D
• la partie 2D des cartes graphiques est nettement moins performante que la partie 3D

Bref, la conclusion s'imposait d'elle même, il fallait trouver un moyen d'accélerer tout ça en utilisant la partie 3D de la carte graphique.
2 solutions ont alors été développées qui répondent à cette problématique : XGL par Novell/Suse et AIGLX par Fedora/RedHat.

XGL

XGL a été la première solution présentée par Novell au tout début de l'année 2006. Son développement a fait l'objet de quelques critiques, en effet, il a principalement été réalisé de manière non-ouverte. Les craintes quand a la fermeture du projet ou du code ont depuis été levées.

Le schéma de principe :

Le schéma ci-dessus présente XGL dans son implémentation Xglx, c'est à dire utilisant 2 serveurs X. Il existe une autre implémentation, Xegl, encore à l'état de projet, qui se baserait sur les EGL, des bibliothèques openGL censées parler directement à la carte graphique.

Comme on le voit sur le schéma, Xgl va donc jouer un double rôle, il est simultanément un client X pour les applications et un serveur X utilisant openGL. Au démarrage, Il va dialoguer avec libGL (et donc le serveur X sous-jacent) et obtenir un rendu 3D direct. Ainsi, toutes les opérations du serveur XGL sont susceptibles d'être accélérées par la carte graphique et en particulier par sa partie 3D. En particulier, toutes les opérations d'un gestionnaire de composition (compiz, beryl par exemple) seront accélérées du moment que celui-ci utilise openGL.

Cela fonctionne très bien mais à quand même quelques défauts relativement gênant : comme pour tout rendu direct, on dit au revoir à la transparence réseau ; la nécessité d'avoir 2 serveurs X tournant simultanément augmente la mémoire occupée ainsi que la complexité du système ; enfin, et c'est le plus gênant, il est impossible pour les autres applications 3D (les jeux par exemple) d'obtenir un rendu direct vers la carte graphique. Elles n'obtiennent au mieux qu'un rendu indirect par le serveur XGL, ce qui pose un problème de performance.

Les 2 derniers problèmes sont liés à l'implémentation Xglx et devrait disparaitre avec Xegl. Mais cette dernière n'est encore que théorique.

Bibliographie

• XAA (Wikipedia)
• EXA (Wikipedia)
• Composite
• XGL
• How XGL works

Plan général

1. Les bases, le rendu 2D
2. Le rendu 3D direct
3. Le rendu 3D indirect
4. Composite et XGL
5. AIGLX
6. Suite et fin (ou comment ne plus avoir d'idée pour le titre)

Préambule

Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.

De quoi on va causer

Nous avons vu dans la première partie, l'architecture client/serveur du système X11. Evidemment, il n'a pas échappé à votre oeil de lynx que le schéma ne mentionnait que la 2D et ne faisait qu'une vague référence à la 3D. C'est tout à fait normal, au moment où X11 a été inventé (vers 1984), la 3D n'était pas particulièrement développé et l'architecture n'en a pas forcément tenu compte d'emblée.
Heureusement pour nous, cette lacune a été comblée depuis et X peut maintenant gérer la 3D. C'est ce que nous allons voir maintenant (tout au moins une partie).

Comment ça marche donc ?

Avec X, la gestion de la 3D au niveau des applications repose sur une API (interface de programmation) assez connue nommée OpenGL. Cette API offre aux application un ensemble de fonctions qui permettent de dessiner en 3D (Direct3D fait de même sous MS-Windows).
Sous GNU/linux (et les autres), c'est le projet Mesa3D qui implémente OpenGL et founis la bibliothèque qui va bien aux applications, la libGL.

A ce stade, on est encore au niveau de l'application et pas encore de la carte graphique, et le problème, c'est que celle-ci ne comprend pas directement l'OpenGL. On va donc avoir forcément une transformation quelque part. C'est ce qu'on appellera le rendu 3D et suivant la méthode il pourra être direct ou indirect.

Le rendu direct

Il est représenté dans le schéma ci-dessus. Dans le rendu direct, l'application 3D va s'adresser à la libGL pour son affichage. La libGL va alors communiquer directement avec le serveur X, demander et obtenir l'autorisation d'accéder à la partie 3D de la carte graphique.
Une fois le droit d'accès donné, la libGL va convertir les commandes OpenGL en commandes compréhensibles par la carte et les envoyer directement à la carte 3D. Ces 2 dernières étapes mettent en jeu le pilote 3D lequel est fortement intriqué avec la libGL.

Dit comme ça, on voit pas trop l'intérêt ; mais en réalité, celà signifie que le traitement 3D est directement effectué par la carte (d'où son nom ), aucun passage par le serveur X et donc nettement moins de traitement au niveau du CPU. On a donc une accélération 3D complète de l'application.

L'inconvénient majeur de cette méthode, c'est qu'il faut dire au revoir à la transparence réseau, en effet, l'application accède à la libGL au niveau client X et cette dernière accède directement au matériel ; il est donc impossible d'avoir de l'affichage déporté avec cette méthode.

Pendant ce temps là, les applis non-3D continuent bien sur à utiliser le rendu 2D classique que nous avons déjà vu.

Les trackback étant encore spammés malgré spamplemousse et la fermeture des trackbacks/commentaires après quelques mois, j'ai décidé d'en rajouter une couche avec le plugin spamtimeout pour dotclear.

Ce plugin permet de générer une url pseudo-aléatoire qui périme après 20 minutes, un spammeur doit donc aller vite si il veut faire un trackback. On verra ce que ça donne avec le temps.