Au cas où ça intéresserait des gens, voici un petit retour d'expérience sur le développement de Gecko (Firefox) / Linux et comment X est un gros boulet qu'on se traîne:
Les pixmaps X. Ce sont des images bitmap stockées du côté serveur X, c'est-à-dire des images en mémoire vidéo, comme les fameuses "textures" d'OpenGL. C'est très bien de stocker des images en mémoire vidéo, donc l'utilisation de pixmaps X a toujours été recommandée (en particuler en conjonction avec XRender mais pas seulement). Le problème vient justement de cette redondance entre pixmaps X et textures OpenGL. À partir du moment où l'on commence à utiliser OpenGL, on se trouve dans une situation où l'on a besoin de convertir efficacement des pixmaps en textures. C'est ce que fait l'extension texture_from_pixmap. Le problème est que les implementations de cette extension sont catastrophiquement buggées. En particulier dans les pilotes NVIDIA proprio et Intel libre. Conséquence: on ne peut pas activer l'accélération OpenGL du compositage dans Firefox tant qu'on ne se sera pas complètement débarrassés de l'utilisation de pixmaps.
XRender. C'était censé être une super API d'accélération 2D, une sorte de Direct2D avant l'heure. Le problème est que les performances des implementations de XRender varient si grandement qu'on ne peut pas savoir à quoi s'attendre. XRender peut être beaucoup plus rapide... ou beaucoup plus lent que du rendu logiciel.
Les erreurs X. C'est le cas d'école d'un système de gestion des erreurs raté. Les erreurs X sont asynchrones, donc pour obtenir le code d'erreur d'une fonction précise il faut synchroniser (XSync) juste après, et la synchronisation peut coûter extrêmement cher (surtout si le serveur X est ailleurs sur le réseau), donc on ne peut généralement pas se le permettre. Conséquence: on doit gérer les erreurs de façon vraiment asynchrone, ce qui veut dire que quand on reçoit une erreur, c'est généralement bien après qu'elle se soit produite... conséquence: il est alors généralement trop tard pour récupérer. Conséquence: les gestionnaires d'erreurs X consistent presque tous a simplement interrompre l'exécution du programme: boum, plantage! C'est le cas du gestionnaire d'erreurs X par défaut, de celui de GDK, et de celui de Mozilla. Il n'y a pas trop d'autre solution en général. Le pire est que les erreurs X peuvent se produire un peu n'importe quand, et ça dépend souvent de détails comme le pilote, le numéro de version du serveur... Une bonne partie des plantages "inexpliqués" de Firefox sous linux sont des erreurs X. (On peut le voir ici)
Gecko a besoin de savoir, avant de demander un contexte OpenGL, si c'est bien raisonnable: en effet, sur certains systèmes (problème avec un pilote, le serveur, etc), créer un contexte OpenGL résulte en un plantage ou une erreur X, ce qui revient au même (cf. point 3). Donc on veut implémenter une "liste noire" de systèmes/de pilotes où il faut éviter de toucher à OpenbGL. Le problème c'est que X est la seule plate-forme où on ne peut pas obtenir ces informations sans... créer un contexte OpenGL (et appeler glGetString)! On peut bien appeler glXQuery{Client|Server}String mais ça donne très peu d'informations. C'est la raison pour laquelle dans Firefox 4 et 5 il était difficile d'activer WebGL. On a résolu ça dans Firefox 6 en forquant un processus séparé qui crée un contexte OpenGL et obtient les informations, comme ça s'il planté c'est pas grave.
# Comment X penalise Firefox / Linux
Posté par Benoit Jacob . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 10. Dernière modification le 21 février 2012 à 14:36.
Au cas où ça intéresserait des gens, voici un petit retour d'expérience sur le développement de Gecko (Firefox) / Linux et comment X est un gros boulet qu'on se traîne:
Les pixmaps X. Ce sont des images bitmap stockées du côté serveur X, c'est-à-dire des images en mémoire vidéo, comme les fameuses "textures" d'OpenGL. C'est très bien de stocker des images en mémoire vidéo, donc l'utilisation de pixmaps X a toujours été recommandée (en particuler en conjonction avec XRender mais pas seulement). Le problème vient justement de cette redondance entre pixmaps X et textures OpenGL. À partir du moment où l'on commence à utiliser OpenGL, on se trouve dans une situation où l'on a besoin de convertir efficacement des pixmaps en textures. C'est ce que fait l'extension texture_from_pixmap. Le problème est que les implementations de cette extension sont catastrophiquement buggées. En particulier dans les pilotes NVIDIA proprio et Intel libre. Conséquence: on ne peut pas activer l'accélération OpenGL du compositage dans Firefox tant qu'on ne se sera pas complètement débarrassés de l'utilisation de pixmaps.
XRender. C'était censé être une super API d'accélération 2D, une sorte de Direct2D avant l'heure. Le problème est que les performances des implementations de XRender varient si grandement qu'on ne peut pas savoir à quoi s'attendre. XRender peut être beaucoup plus rapide... ou beaucoup plus lent que du rendu logiciel.
Les erreurs X. C'est le cas d'école d'un système de gestion des erreurs raté. Les erreurs X sont asynchrones, donc pour obtenir le code d'erreur d'une fonction précise il faut synchroniser (XSync) juste après, et la synchronisation peut coûter extrêmement cher (surtout si le serveur X est ailleurs sur le réseau), donc on ne peut généralement pas se le permettre. Conséquence: on doit gérer les erreurs de façon vraiment asynchrone, ce qui veut dire que quand on reçoit une erreur, c'est généralement bien après qu'elle se soit produite... conséquence: il est alors généralement trop tard pour récupérer. Conséquence: les gestionnaires d'erreurs X consistent presque tous a simplement interrompre l'exécution du programme: boum, plantage! C'est le cas du gestionnaire d'erreurs X par défaut, de celui de GDK, et de celui de Mozilla. Il n'y a pas trop d'autre solution en général. Le pire est que les erreurs X peuvent se produire un peu n'importe quand, et ça dépend souvent de détails comme le pilote, le numéro de version du serveur... Une bonne partie des plantages "inexpliqués" de Firefox sous linux sont des erreurs X. (On peut le voir ici)
Gecko a besoin de savoir, avant de demander un contexte OpenGL, si c'est bien raisonnable: en effet, sur certains systèmes (problème avec un pilote, le serveur, etc), créer un contexte OpenGL résulte en un plantage ou une erreur X, ce qui revient au même (cf. point 3). Donc on veut implémenter une "liste noire" de systèmes/de pilotes où il faut éviter de toucher à OpenbGL. Le problème c'est que X est la seule plate-forme où on ne peut pas obtenir ces informations sans... créer un contexte OpenGL (et appeler glGetString)! On peut bien appeler glXQuery{Client|Server}String mais ça donne très peu d'informations. C'est la raison pour laquelle dans Firefox 4 et 5 il était difficile d'activer WebGL. On a résolu ça dans Firefox 6 en forquant un processus séparé qui crée un contexte OpenGL et obtient les informations, comme ça s'il planté c'est pas grave.