David Madore's WebLog: et maintenant sans WebGL

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #1990 [older|newer] / Entrée #1990 [précédente|suivante]:

(dimanche)

et maintenant sans WebGL

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.

↑Entry #1990 [older|newer] / ↑Entrée #1990 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées