Dans l'entrée précédente je me
plaignais que les navigateurs Web n'étaient pas capables
d'afficher, dans canvas sur une machine moderne, 6720 lignes en
40ms
. En fait, c'est Plus Compliqué Que Ça® : Firefox est très
lent, mais Chrome s'en sort parfaitement (et Opera, l'autre navigateur
que je suis susceptible de tester, tombe quelque part entre les
deux).
Vous pouvez essayer sur cette page (également temporaire), qui est, en gros, la version sans WebGL de la même chose qu'hier : c'est beaucoup plus beau parce cette fois je peux tracer des lignes de 0.25 pixels de large (et tracer les points, aussi), mais sous Firefox, au moins dans certaines combinaisons version/OS, c'est abominablement lent. Sous Chrome (là aussi, au moins dans certaines combinaisons version/OS) c'est exactement ce que je veux obtenir, une animation fluide et élégante.
La raison de cette différence de vitesse (d'un facteur au moins
20 !) me semble assez obscure. Ma première explication était que
Chrome utilise la bibliothèque
graphique Skia
(écrite par Google) alors que Firefox
utilise Cairo, et sous Linux
cette dernière bibliothèque utilise
l'extension XRender
du serveur X, qui est apparemment
lente[#] en la matière. Ça
explique pourquoi, sous Linux, le processus qui prend beaucoup
de CPU quand on affiche la page en question,
c'est Xorg et pas Firefox. Mais en fait, je ne sais pas
si cette explication est la bonne : parce qu'on me souffle que Firefox
est tout aussi lent sur cette page sous Windows que sous Linux (alors
que sous Windows je crois qu'il utilise la même bibliothèque
graphique, Skia, que Chrome, et de toute façon il n'y a pas
de XRender pour expliquer la lenteur), et
d'ailleurs IE9 est également bien lent. A contrario,
Firefox 12 (celui qui est actuellement
en nightly) a créé un nouveau mécanisme de rendu
graphique
appelé Azure,
et
qui est
censé depuis avant-hier utiliser la fameuse bibliothèque Skia même
sous Linux : j'espérais donc qu'en utilisant un Firefox 12 tout frais
compilé des sources d'aujourd'hui obtenir une performance comparable à
celle de Chrome : déception, il se comporte exactement comme mon
Firefox 10 (c'est-à-dire autour de 2 images par seconde au lieu des 25
recherchées). Mon about:support sous ce Firefox 12
prétend bien utiliser Skia, mais X continue à prendre
tout le CPU, donc je soupçonne qu'il passe quand même
par XRender… je suis perplexe.
Ajout () : Merci à Benoît Jacob pour ses explications (cf. les commentaires). Le truc est donc bien que Firefox passe par Cairo qui passe par XRender qui est lent, alors que Chrome passe par Skia qui est beaucoup plus rapide. Skia est utilisé par Firefox pour Mac OS, et devrait aussi être utilisé sous Linux (dans le cadre de la couche Azure) à partir de Firefox 12 ou 13 (note : la version qui sort demain est la 10), mais pour l'instant ce n'est pas le cas même dans les nightlies. Rendez-vous dans six mois, donc.
Ça devient de plus en plus impossible de savoir quels chemins logiciels emprunte un appel à une fonction graphique : il y a tellement de couches superposées qu'on n'y comprend vraiment plus rien. Surtout que ces couches peuvent s'empiler de toutes sortes de manières : Cairo a ou va avoir un backend Skia, XRender a ou va avoir une implémentation OpenGL, voire plusieurs différentes, sans compter que Cairo pourrait lui aussi avoir un backend OpenGL, etc.
Et je m'énerve aussi du bordel des navigateurs à l'heure actuelle : à chaque fois que je veux utiliser une feature garantie par les standard du Web (enfin, « standards », ce qui en tient lieu), et je n'ai pas l'impression d'aller chercher des choses incroyablement tordues, j'ai à peu près une chance sur deux que ça marche sur Firefox, une chance sur trois que ça marche sur Chrome, une chance sur quatre que ça marche sur Opera, et ça fait dans les une chance sur vingt-quatre que ça marche sur les navigateurs que je suis susceptible de tester (les autres, vu qu'ils ne s'intéressent pas à mon OS, je ne m'intéresse pas trop à eux en retour…). Chrome a tendance à être plus rapide (l'exemple dont je parle ici est quand même un cas tellement extrême qu'on peut vraiment appeler ça un bug de Firefox), mais en contrepartie, il gère le SVG comme un pied (dès qu'on veut faire du clipping ou du masking, il n'y a plus personne), il n'a toujours pas de support MathML, bref, il sert plus de terrain de jeu à Google (parce qu'à côté de ça on a du SPDY, du nativeclient ou du Dart, les trucs qui ne servent vraiment à rien) mais pour implémenter complètement le HTML5 on repassera. Et comme Firefox est une usine à gaz, je ne sais pas ce qui vaut mieux[#2].
[#] Enfin, en disant ça je n'explique rien : il n'y a pas de raison évidente pour laquelle XRender serait plus lente que Skia pour tracer des lignes antialiasées (l'idée d'avoir une extension dédiée dans le serveur X est, je suppose, au cas où il y aurait du matériel graphique qui accélère les opérations en question — je n'ai aucune idée de s'il y en a — mais ça n'explique pas pourquoi quand il n'y a pas de telle accélération ce ne serait pas tout aussi rapide que de tout faire dans la bibliothèque). Pour perdre un facteur 20, il faut quand même une vraie raison !
[#2] Du moins, comme
développeur Web je ne sais pas ce qui vaut mieux. Comme utilisateur,
je préfère clairement Firefox, pour la raison qu'il m'offre plein
d'options de configuration alors que Chrome décide systématiquement
qu'il sait mieux que moi ce qui est bon pour moi. Par exemple,
Firefox et Chrome ont tous les deux choisi de ne plus afficher
le http:// en tête des URL qui commencent
ainsi ; mais Firefox a une variable de
configuration, browser.urlbar.trimURLs (que je me suis
empressé de désactiver) qui contrôle ce comportement, alors que dans
Chrome ils ont décidé que c'était comme ça et si on n'est pas content
c'est le même prix.