SVG ou Canvas, que choisir ?

  • Profil : Expert
  • Technologie : (X)HTML
  • Auteur : Jeremie Patonnier
  • Mise à jour : 25/01/2012

En bref

Depuis plusieurs années que je m’intéresse à SVG et aux nouvelles possibilités qu’offre HTML5, on me pose régulièrement cette même question : « Quel est le mieux entre SVG et Canvas ? ». Je réponds alors stoïquement et laconiquement : « Les deux mon capitaine, ça dépend ». En effet, ça dépend, voilà donc un petit guide pour vous aider à choisir entre ces deux technologies.

Voyons tout d’abord ce que ces technologies ont en commun. Après tout, s’il est si difficile de choisir entre l’une et l’autre c’est qu’elles semblent offrir les mêmes choses... Mais quoi exactement ? Pour mémoire, SVG est un format d’image vectoriel et Canvas une balise HTML5 permettant d’y dessiner ce que l’on veut. Toutes deux permettent donc de créer des images directement dans le navigateur. Dès l’instant où vous allez vouloir utiliser les capacités de votre navigateur pour produire des images, vous allez donc vous poser la fatidique question. Et soyons honnêtes, les cas d’usage de ces deux technologies se recoupent souvent.

Il est très rare que dans le cadre du Web nous ayons deux standards qui fassent la même chose... En fait, cela n’arrive jamais. En effet, si ces deux technologies cherchent en apparence à atteindre le même objectif (dessiner), elles ne vont pas du tout le faire de la même manière ni dans des conditions identiques, et c’est là que va se nicher le délicat choix entre l’une et l’autre. J’en profite ici pour évacuer immédiatement une question récurrente liée au support des standards : tous les navigateurs supportant l’une de ces technologies supportent également l’autre, ce qui inclut Internet Explorer 9 et suivants.

Vecteurs contre bitmap

La première différence entre ces deux technologies tient aux types de données qu’elles manipulent. SVG est un format vectoriel, là où Canvas est un format bitmap. On a donc d’un côté, des formes définies à l’aide de points et de courbes, et de l’autre une bouillie de pixels anonymes.

La différence entre les deux va donc se jouer sur des questions assez simples finalement : si vous devez envisager un redimensionnement sans perte de qualité, SVG sera plus indiqué. À l’inverse, si vous devez réaliser des opérations complexes sur les pixels (ce qui est le cas quand vous devez interpoler deux images ou si vous travaillez sur un flux vidéo en temps réel par exemple) c’est Canvas qui sera le plus indiqué.

Déclaratif contre programmatif

Une autre différence de fond entre ces deux technologies tient à la façon de les utiliser. SVG est un langage qui repose sur une syntaxe XML, il est dit déclaratif : en clair, vous dites explicitement au navigateur ce qu’il doit dessiner et il se débrouillera au mieux de ses capacités pour le faire. Canvas lui, repose sur une API (plusieurs en fait, mais là, je vais me concentrer sur l’API de dessin 2D qui est la plus proche de SVG) qui est accessible via JavaScript : vous allez devoir programmer la façon dont le navigateur va devoir dessiner ce que vous voulez.

Ces deux approches ont chacune leurs avantages et leurs défauts. Par exemple, si vous avez une question de performance à gérer, Canvas sera sans doute plus approprié. En effet, dans une approche programmative, vous contrôlez la méthode de dessin avec beaucoup plus de précision et pouvez mettre en place des stratégies d’optimisations spécifiques selon vos propres besoins. Par contre, dans une approche déclarative, c’est le navigateur qui décidera de la façon de dessiner votre image en effectuant lui même les opérations d’optimisation qu’il estime nécessaires.

Prenons le problème sous un autre angle : si vous devez dessiner des objets complexes, SVG sera sans doute plus adapté. En effet, la méthode déclarative de SVG propose, par essence, un degré d’abstraction plus important que l’API 2D de la balise canvas (et je ne vous parle même pas de WebGL). Elle vous permet donc de dessiner des courbes extrêmement complexes avec un effort ridicule en comparaison de Canvas (sans même parler des logiciels de dessin qui vous offrent une interface hyper intuitive pour dessiner ces formes et les exporter directement en SVG). À l’inverse, si vous devez mettre en œuvre des interactions complexes entre formes, la souplesse de l’API Canvas 2D vous offrira des outils bien plus simples à manipuler pour contrôler l’efficacité et les performances de vos dessins.

DOM or not DOM, zat iz ze question

SVG reposant sur une syntaxe XML, son interprétation par un navigateur conduit à la construction d’un arbre DOM qui comprendra l’ensemble des éléments qui constituent l’image. De son côté, Canvas n’est pas encombré par cette contrainte et une image dessinée via cette API ne donnera pas lieu à sa représentation dans un arbre DOM.

La question est donc : « Avez-vous besoin d’un arbre DOM lié à votre image ? ». Disposer d’un tel arbre offre certains avantages. D’un point de vue accessibilité par exemple, un arbre DOM sera visible par les technologies d’assistance et en cas de besoin, vous pouvez même envisager de rajouter des rôles Aria à votre arbre pour qu’il soit plus facilement compris. D’un point de vue plus technique, chaque élément de l’image étant accessible via l’API DOM, il est extrêmement facile de les manipuler individuellement et partiellement sans avoir à vous soucier de garder à la main un état pour chacun d’entre eux.

Mais ne pas avoir d’arbre DOM a aussi de nombreux avantages en particulier pour les performances. En effet, créer et maintenir un arbre DOM requiert d’importantes ressources surtout en terme de mémoire. Accessoirement, l’API DOM est notoirement lente et cela se fera particulièrement ressentir si vous devez traiter de très nombreux éléments très vite (par exemple pour certaines animations) ou simultanément (pour les jeux par exemple)

Considérations annexes

Un dernier point qu’il ne faut pas oublier : SVG, contrairement à Canvas, est un vrai format d’image indépendant. En conséquence, vous pouvez l’utiliser partout où l’on peut traditionnellement utiliser des images : en temps qu’arrière-plan ou contenu généré via CSS ou au sein d’une balise img en HTML. De même en temps que format d’image, il existe pléthore de logiciels qui permettent d’exporter au format SVG ce qui n’est pas du tout le cas avec Canvas.

Je vous ai également épargné les évidences comme, par exemple, le fait qu’en l’absence de JavaScript, les images Canvas ne seront pas affichées là où les images SVG, elles, le seront.

Conclusion

Chacune des ces technologies a donc ses avantages et ses inconvénients. Là où cela devient intéressant, c’est quand vous commencez à mixer les deux : les possibilités ouvertes sont alors quasi infinies. En effet, certaines fonctionnalités natives de SVG sont très complexes à implémenter avec Canvas (par exemple, les formes de découpe via l’élément clipPath). De même réaliser des transformations au niveau des pixels est impossible avec SVG (par exemple réaliser un détourage dynamique de type "fond vert" sur la base d’une image rasterisée). Ainsi, si vous utilisez les deux technologies simultanément, vous arriverez à faire des choses étonnantes. Par exemple un détourage vidéo réalisé avec Canvas qui, via Javascript, génère dynamiquement un éléments SVG clipPath permettant de superposer cet élément vidéo sur du contenu HTML, tout en laissant ce contenu HTML sélectionnable. Les possibilités étant énormes, voila deux petits exemples concrets pour vous faire une idée : Un puzzle vidéo (à voir avec Firfox pour un meilleur résultat) et une galerie d’image composite.

Prenez le temps d’expérimenter les deux technologies et de bien regarder celle qui correspondra le mieux à vos cas d’usage. Céder à la facilité en n’en utilisant qu’une seule vous conduira nécessairement à des impasses ou à des pertes de temps liées au syndrome "réinvention de la roue".

Une question, une remarque ? Écrivez à l'auteur.

2 Messages de forum

Répondre à cet article

Page valide XHTML 1 Strict, CSS2 et accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards, voici pourquoi.
Site hébergé par yterium (depuis 2010) et par l'APINC (2002-2010) . Propulsé par SPIP.