En SVG, que es más ligero: ¿polígono o ruta?

Question

Estoy representando un mapa compuesto por más de 600 elementos SVG alineados en un plano cartesiano. Necesito que sean elementos separados porque quiero que respondan individualmente a los eventos del mouse, etc.

Mi pregunta es: con el fin de aplicar muchas transformaciones como "traducir" (cambiando sus posiciones), por ejemplo, la opción es "más ligera" para los navegadores?

polígonos Rendering como este hexágono:

<polygon points="43.301270189221924,55 43.301270189221924,65 51.96152422706631,70 60.6217782649107,65 60.6217782649107,55 51.96152422706631,50"></polygon> 

... o crearlos como caminos como éste:

<path d="M43.301270189221924,55L43.301270189221924,65L51.96152422706631,70L60.6217782649107,65L60.6217782649107,55L51.96152422706631,50Z"></path> 

Por supuesto, puede haber ninguna diferencia. Lo aceptaré como una respuesta también.

Gracias de antemano.

Answer 1

Dudo que haya mucha diferencia, pero si hay alguna, esperaría que polygon fuera marginalmente más rápido, ya que está específicamente diseñado para, ya sabes, polígonos.

De hecho, después de ejecutar dos scripts de creación de perfiles (ver a continuación), mi evaluación anterior parece correcta. Los polígonos son un poco más rápidos que los caminos en todos los navegadores, pero la diferencia es apenas significativa. Así que dudo que realmente necesites preocuparte por esto. Afortunadamente, polygon suena como la opción lógica de todos modos.

de perfiles path:

<svg xmlns="http://www.w3.org/2000/svg"> 
    <g id="paths"></g> 

    <text x="20" y="20" id="out"></text> 

    <script><![CDATA[ 
    var d = "M43.301270189221924,55 L43.301270189221924,65 L51.96152422706631,70 L60.6217782649107,65 L60.6217782649107,55 L51.96152422706631,50 Z"; 

    var paths = document.getElementById('paths'); 
    var path = document.createElementNS("http://www.w3.org/2000/svg", 'path'); 
    path.setAttribute('d', d); 

    var start = new Date(); 
    for (var i = 0; i < 20000; i++) 
    { 
     var el = path.cloneNode(true); 
     el.setAttribute('transform', 'translate(' + ((i * 20) % 1000) + ',' + ((i/50) * 20) + ')'); 
     paths.appendChild(el); 
    } 

    setTimeout(function() { 
     document.getElementById('out').textContent += 'Path: ' + (new Date() - start) + 'ms'; 
     // paths.parentNode.removeChild(paths); 
    }, 10); 

    ]]> 
    </script> 
</svg> 

Y lo mismo para polygon:

<svg xmlns="http://www.w3.org/2000/svg"> 
    <g id="polygons"></g> 

    <text x="20" y="20" id="out"></text> 

    <script><![CDATA[ 
    var points = "43.301270189221924,55 43.301270189221924,65 51.96152422706631,70 60.6217782649107,65 60.6217782649107,55 51.96152422706631,50"; 

    var polygons = document.getElementById('polygons'); 
    var polygon = document.createElementNS("http://www.w3.org/2000/svg", 'polygon'); 
    polygon.setAttribute('points', points); 

    var start = new Date(); 
    for (var i = 0; i < 20000; i++) 
    { 
     var el = polygon.cloneNode(true); 
     el.setAttribute('transform', 'translate(' + ((i * 20) % 1000) + ',' + ((i/50) * 20) + ')'); 
     polygons.appendChild(el); 
    } 

    setTimeout(function(){ 
     document.getElementById('out').textContent += 'Polygons: ' + (new Date() - start) + 'ms'; 
     // polygons.parentNode.removeChild(polygons); 
    }, 10); 

    ]]> 
    </script> 
</svg> 

Answer 2

terminamos cambiando mi comentario a una respuesta ...

No sé mucho sobre SVG en detalle, pero ... Asumiría que la transformación en sí tomaría la misma cantidad de tiempo, ya que simplemente estaría cambiando los valores de los puntos. rojo en la memoria. Incluso si no fuera así, la "pesadez" adicional probablemente sería ampliamente superada por el hecho de que la representación es lo que requiere la mayor cantidad de recursos de cualquier otra cosa. Consulte http://en.wikipedia.org/wiki/File:10-simplex_t03.svg para ver un ejemplo con montones y montones de elementos SVG.

De todos modos, si es que no hay una diferencia de rendimiento significativa, entonces yo también estaría de acuerdo con la etiqueta del polígono, pero no solo por la semántica. Evitaría que accidentalmente se haga curvo el hexágono, y la sintaxis es más simple.