Tres modelos de gráfico: canvas, SVG y CSS

Qué guarda cada modelo

La pregunta que separa los tres motores no es “¿qué puede dibujar?” —los tres pueden dibujar un círculo rojo— sino “¿qué recuerda el navegador después de dibujarlo?”. La respuesta cambia el coste de cada operación posterior, y con ella la arquitectura completa de tu aplicación.

CSS recuerda cajas. El motor construye un árbol de cajas a partir del DOM, resuelve tamaños y posiciones con los algoritmos de layout, y después pinta cada caja con las propiedades de fondo, borde, sombra, filtro y transformación que le correspondan. Todo lo que CSS dibuja está anclado a un elemento del documento, hereda su geometría del layout y participa en el modelo de eventos sin que tú hagas nada. Esa es su virtud y su límite: no puedes dibujar algo que no sea una caja, y la caja la decide el layout, no tú.

SVG recuerda formas. Un <circle> es un nodo del DOM, con sus atributos, sus estilos calculados, su árbol de accesibilidad y sus listeners. Si cambias su atributo r, el navegador vuelve a rasterizar la escena por ti. No hay que redibujar nada a mano porque el navegador conserva la descripción geométrica completa y la reproyecta cada vez que hace falta. A esto se le llama modo retenido: la escena está retenida en una estructura de datos que el sistema gráfico posee.

El canvas 2D no recuerda nada. Tiene un búfer de píxeles y un contexto con un puñado de variables de estado. Cuando llamas a ctx.fill(), el navegador modifica píxeles y olvida inmediatamente por qué los modificó. No hay ningún objeto “círculo” al que puedas cambiarle el radio, porque nunca hubo un círculo: hubo una llamada que dejó un rastro de color. A esto se le llama modo inmediato, y no es un detalle de la API sino la decisión de diseño de la que se derivan todas las demás.

El mismo círculo, tres veces

Nada aclara tanto la diferencia como escribir la misma figura en los tres modelos y mirar qué queda vivo después.

<!-- CSS: la forma es una caja con border-radius --><div class="bolita"></div><style>  .bolita { width: 80px; height: 80px; border-radius: 50%; background: #f38ba8; }</style>

<!-- SVG: la forma es un nodo del DOM --><svg width="120" height="120" viewBox="0 0 120 120">  <circle cx="60" cy="60" r="40" fill="#a6e3a1" /></svg><script>  // El nodo sigue existiendo. Cambiarlo basta: el navegador redibuja.  document.querySelector('circle').setAttribute('r', 20);</script>

<!-- Canvas: la forma es el efecto de una llamada, y desaparece como concepto --><canvas id="c" width="120" height="120"></canvas><script>  const ctx = document.getElementById('c').getContext('2d');  ctx.fillStyle = '#89b4fa';  ctx.beginPath();  ctx.arc(60, 60, 40, 0, Math.PI * 2);  ctx.fill();  // Para "cambiar el radio" hay que borrar y volver a dibujarlo todo.  ctx.clearRect(0, 0, 120, 120);  ctx.beginPath();  ctx.arc(60, 60, 20, 0, Math.PI * 2);  ctx.fill();</script>

Los tres producen píxeles indistinguibles. La diferencia aparece en la línea siguiente. En CSS y en SVG, modificar el círculo es una operación local sobre un objeto que existe; el navegador se encarga de la consecuencia visual y del repintado mínimo. En canvas, “modificar el círculo” no es una operación posible: solo puedes reconstruir el fotograma entero. Si tu escena tiene ocho elementos eso da igual. Si tiene ochenta mil, es precisamente lo que quieres, porque reconstruir ochenta mil rectángulos en un búfer plano es mucho más barato que mantener ochenta mil nodos del DOM con su estilo calculado, su caja y su árbol de accesibilidad.

Los tres muros

Cada modelo tiene un muro contra el que choca, y los tres son predecibles.

CSS choca contra la forma arbitraria. Mientras necesites rectángulos, círculos, degradados y sombras, CSS es imbatible porque el navegador lo acelera, lo anima en el compositor y lo hace accesible gratis. En cuanto necesitas una polilínea con datos, una curva que responde a un cálculo o un recorte que no es una elipse, empiezas a apilar pseudoelementos y clip-path con polígonos generados a mano, y ese es el aviso de que estás en el modelo equivocado.

SVG choca contra el número de elementos. No hay una cifra mágica, porque depende del dispositivo y de con qué frecuencia cambian, pero el orden de magnitud es claro: unos pocos miles de nodos que se actualizan cada fotograma bastan para hundir el hilo principal en cualquier portátil. El coste no está en rasterizar las formas, está en mantener el DOM: recalcular estilo, invalidar layout y reconstruir el árbol de pintura para miles de nodos sesenta veces por segundo.

El canvas choca contra todo lo que el DOM te daba gratis. Accesibilidad, selección de texto, búsqueda en la página, zoom del navegador con nitidez, impresión vectorial, inspección en las herramientas de desarrollo, eventos por elemento. Ninguna de esas cosas existe dentro de un canvas, y varias de ellas —la accesibilidad, sobre todo— no se pueden recuperar del todo por mucho código que escribas.

Cómo se usa este mapa

En la práctica el mapa se recorre con tres preguntas encadenadas, y en este orden.

El orden importa porque los tres modelos no cuestan lo mismo en mantenimiento. CSS es el más barato de escribir y el más caro de forzar; canvas es el más caro de escribir y el que menos se rompe cuando el volumen crece. Empezar por el más barato que resuelva el problema es una regla que envejece bien.

Y hay una cuarta respuesta que la tabla no recoge: los tres a la vez. Un mapa interactivo real dibuja las teselas en canvas, los marcadores clicables en SVG encima y el panel de controles en CSS. No hay ninguna regla que te obligue a elegir uno solo, y las interfaces gráficas serias de la web casi nunca lo hacen.