¿Los símbolos de reutilización mejoran el rendimiento de SVG?

Question

Suponiendo una, navegador de escritorio SVG-apoyo relativamente moderno y un SVG consta de cientos de, nodos simples similares:

1. El documento podría ser configurado como muchos elementos de forma individuo (<circle>, <line>, etc.) con sus propios atributos definidos.
2. El documento podría configurarse como unos pocos elementos <symbol> y muchas instancias individuales <use> que los colocan y les asignan un tamaño adecuado (W3 spec).

entiendo las razones semánticas y el código de mantenimiento para usar <symbols>/<use>, pero no estoy preocupado por los que ahora, estoy estrictamente tratar de optimizar la prestación, la transformación y el rendimiento de la actualización DOM. Pude ver <symbol> trabajando de manera similar a la reutilización de sprites en Flash, conservando la memoria y siendo generalmente una buena práctica. Sin embargo, me sorprendería si los proveedores de navegadores hubieran estado pensando de esta manera (y este no es realmente el intento de la función).

Editar: No estoy esperando los símbolos de base a ser cambiado o añadido a lo largo del ciclo de vida del SVG, sólo las ubicaciones de instancia, tamaños, etc.

• ¿Hay patrones claros a <symbol>/<use> rendimiento?
• ¿Qué tan idiosincrásico es para implementaciones de navegador individuales?
• ¿Hay diferencias entre reutilizar <symbol> vs <g> vs <svg> anidados?

Answer 1

Si cambia el contenido de un elemento ag o svg, una IU puede ver el área en la que se dibujaron los contenidos anteriores y dónde se dibujará y simplemente redibujar esas dos áreas, incluso volver a dibujar solo una vez si ellos son lo mismo, por ejemplo cambiando el color de una forma.

Si actualiza el contenido de un símbolo, todas las instancias deben volver a dibujarse. Es más difícil hacer eso calculando para cada instancia donde las partes viejas y nuevas para volver a dibujar son las áreas que pueden verse afectadas por las transformaciones y más simples para volver a dibujar todas las partes de todas las instancias. Algunos navegadores pueden hacer lo primero y algunos lo último.

En cualquier caso, una IU debe como mínimo rastrear los cambios en el símbolo y propagar esos cambios a todas las instancias. Es más que probable que tenga algunos gastos generales.

Por supuesto, si solo está moviendo instancias de símbolos individuales y el contenido es estático, entonces no se requiere seguimiento y es probable que el rendimiento sea similar.

Answer 2

Le aconsejo que no anide < use> elements profundamente. Se sabe que esto causa ralentizaciones en la mayoría de los navegadores, ver here y here.

En el caso general, aunque debe ser rápido, al menos mientras la plantilla misma no se modifique demasiado (ya que si lo hace, entonces cada una de las instancias debe actualizarse también, y cada una de ellas puede diferir de el resto debido a la herencia de CSS).

Entre < símbolo> y < símbolo> no hay una gran diferencia en un nivel funcional, ambos le permiten definir un sistema de coordenadas (a través del atributo 'viewBox'). Un elemento < g> no le permite hacer eso. Tenga en cuenta que < símbolo> los elementos son invisibles a menos que se haga referencia a ellos en un < use>, mientras que < svg> y < g> son ambos visibles por defecto. Sin embargo, en la mayoría de los casos, es aconsejable hacer que la plantilla sea hija de un elemento < defs>.

Answer 3

Rohit Kalkur comparó la velocidad de representación de la creación de 5000 símbolos SVG utilizando use para crear directamente las formas del símbolo SVG, consulte here. Resulta que la representación de las formas SVG usando use fue casi 50% más lenta. Su razonamiento es que:

El elemento de uso de toma nodos desde el documento SVG, y ellas duplica en un no-expuesto DOM

Teniendo en cuenta esto, supongo que el uso de SVG symbol s es, en el mejor tan eficiente como crear manualmente la forma de symbols.