Journal Dans lequel on revient sur les performances SVG des Firefox

Posté par  (site web personnel) . Licence CC By‑SA.
21
31
mai
2013

Chers lecteurs et chères lectrices,

Vous vous souvenez peut-être de mon précédent journal, Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu abordant brièvement les piètres performances de rendu SVG de Firefox. Un commentaire fort pertinent m'y a suggéré l'utilisation de canvas pour pallier à ces problèmes de performances.
 

Voici donc le résultat, avec la possibilité de passer de canvas à SVG pour comparer : http://ssz.fr/places
Vous remarquerez rapidement que les performances restent sensiblement les mêmes sous Chromium, mais qu'il y a une importante différence avec Firefox.
 

Plus récemment, j'ai fait une autre carte du même genre, avec moins d'éléments, mais plus dynamiques, ce qui rend un canvas moins adapté. La voici : http://ssz.fr/ker - ce n'est pas forcément très utile, ça permet de visualiser les (~1300) toponymes des îles Kerguelen par date d'attribution et par auteur, des premiers en 1772 aux derniers en 1971. Kerguelen est assez pratique pour ça, puisqu'elle a été découverte relativement récemment, et que l'origine de tous les noms a très bien été documentée par la Commission de Toponymie des Terres Australes dans les années 60-70.
 

Bref, avec seulement un millier de points, je me pensais loin de dépasser les limites de l'acceptable pour Firefox, or en SVG c'est tout simplement inutilisable, même après avoir enlevé tous les effets de transparence, et même en réduisant la taille des éléments pour éviter tout chevauchement (j'ai pu remarquer que les chevauchements entre éléments SVG opaques sont bien moins performants qu'entre éléments totalement transparents mais avec une épaisse bordure). J'ai donc fait un test avec des éléments HTML positionnés de manière absolue, au cas où — des span en display:block avec des border-radius, et du transform: scale() pour ajuster les dimensions — et… c'est plus performant que du SVG sur Firefox. Mais moins sur Chromium.
 
Pour avoir les meilleures performances sous Firefox, je me retrouve donc à faire un fond de carte en canvas, un graphique en SVG, et des points en HTML. Sous Chromium, le fond de carte en canvas a de bien meilleures performances qu'en SVG, mais reste quand même utilisable en SVG.

 

En conclusion, il semblerait qu'il faille éviter à tout prix d'utiliser du SVG avec Firefox, canvas a des performances largement supérieures à la fois avec Firefox et Chromium. Pour essayer d'optimiser le rendu suivant le navigateur, j'ai fini par mettre un

var svg = typeof InstallTrigger == 'undefined';

qui met la variable svg à true quand le navigateur est autre que Firefox, pour décider de quelle méthode utiliser ensuite pour le rendu.

  • # Pourquoi pas ...

    Posté par  . Évalué à 4.

    Et quand c'est I.E.6 le navigateur, tu fais quoi?
    ----->[]

    • [^] # Re: Pourquoi pas ...

      Posté par  . Évalué à 10.

      IE6 ? Un navigateur ?

    • [^] # Re: Pourquoi pas ...

      Posté par  (site web personnel) . Évalué à 6.

      Arf… tester sous IE m'a traversé l'esprit pendant quelques secondes, et puis finalement non. Parce qu'il faut pas pousser, quand même.

      • [^] # Re: Pourquoi pas ...

        Posté par  . Évalué à 5.

        C'est triste ton opinion sur IE10 (qui affiche ton site en SVG ou pas sans probleme et juste un petit peu plus lentement que Chrome)

        • [^] # Re: Pourquoi pas ...

          Posté par  . Évalué à 3.

          À l'heure où j'écris, le commentaire de pBpG est dans le négatif, mais pourtant, il n'y a pas que du faux.

          Même sans chercher à corriger les « erreurs » auxquelles Internet Explorer peut être sensible, juste tester, pour voir, donne parfois des résultats surprenants. Ça va du « Dingue, ça marche alors que je fait des trucs super compliqués », au « Beuh… J'ai que du CSS et du HTML, et IE est le seul navigateur à me rendre un écran noir ? » (à l'époque où j'ai eu ça, c'était IE 8).

          Bon… Si on n'a qu'un Linux sous la main, ça vaut pas le coup de s'embêter pour ça. Mais si on y a accès… Faut être curieux, sans forcément s'engager à supporter la bête :-)

        • [^] # Re: Pourquoi pas ...

          Posté par  (site web personnel) . Évalué à 4.

          Je ne doute pas qu'il y ait eu de l'amélioration depuis IE6, mais il ne fonctionne malheureusement toujours pas sous Linux, et les machines virtuelles disponibles sur http://www.modern.ie/ sont distribuées sous forme de nombreux et énormes RAR découpés, c'est vraiment peu pratique. Maintenant que ies4linux est mort, je ne teste simplement plus IE.

  • # Attention au dénigrement publique !

    Posté par  . Évalué à 9.

    En conclusion, il semblerait qu'il faille éviter à tout prix d'utiliser du SVG avec Firefox, canvas a des performances largement supérieures à la fois avec Firefox et Chromium

    Ca ne m'étonnerait pas que linuxfr reçoivent une autre mise en demeure de l'avocat de la W3C pour denigrement d'un format qu'elle a mise tant de temps à normaliser, ou alors de la fondation Mozilla pour avoir pointé du doigt son incompétence à intégrer un format d'image … trollomètre … top départ !

  • # SVG, Canvas et ...

    Posté par  (site web personnel) . Évalué à 3.

    Tu as essayé en DOM?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: SVG, Canvas et ...

      Posté par  (site web personnel) . Évalué à 4.

      Le SVG est dans le DOM, donc oui.

      Et si tu lis attentivement, tu verras que j'ai finalement retenu pour Firefox l'utilisation d'éléments HTML, ce qui est probablement ce que tu entends par DOM [:itm] et tu verras aussi qu'ils sont plus rapides que le SVG, avec Firefox.

      • [^] # Re: SVG, Canvas et ...

        Posté par  . Évalué à 2.

        Le SVG est dans le DOM, donc oui.

        Attention ! Bien que le DOM SVG soit encré au DOM HTML, il s'agit de deux éléments distincts. La logique, les fonctions et les méthodes d'accès ne sont pas les mêmes. Le SVG vient avec ses propres définitions et son propre schéma.

  • # rappelle moi comment on prononce ton nom

    Posté par  . Évalué à 7.

    :)
    merci pour tes retours sur tes expérimentations en tout cas.

    • [^] # Re: rappelle moi comment on prononce ton nom

      Posté par  . Évalué à 1.

      +1 ! La différence est assez monstrueuse, c'est cool d'avoir pris le temps de pousser ça plus loin. Comment tu gère l'affichage des bordures sur les hexagones quand la souris passe dessus ?

      from __future__ import division

      • [^] # Re: rappelle moi comment on prononce ton nom

        Posté par  (site web personnel) . Évalué à 1.

        En SVG évidemment c'est simple à gérer, un simple :hover… mais en canvas, j'ai deux éléments canvas :
        un avec la carte, et un entièrement transparent au-dessus. À chaque évènement mousemove, je détermine sur quel hexagone est la souris (avec des maths que je comprends à moitié) et je dessine cet hexagone uniquement sur le canvas transparent, après avoir effacé l'éventuel hexagone qui y était déjà dessiné auparavant.

        En fait, j'ai aussi un troisième canvas pour le texte, pour pouvoir mettre à jour la légende sans devoir redessiner la carte entièrement.

  • # accélération

    Posté par  (site web personnel) . Évalué à 7.

    Il manque peut être l'accélération matérielle sur ton Firefox ? T'as comparé une version Windows et Linux ? Je sais que sous Linux ils ont du mal à développer l'accélération matérielle (voir ici et pour quelques exemples pas nécessairement pertinents pour le SVG, je ne sais pas)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.