html5 - the - svg on img tag
Cuadros/gráficos interactivos rápidos y receptivos: SVG, Canvas, otros? (4)
Estoy tratando de elegir la tecnología adecuada para actualizar un proyecto que básicamente genera miles de puntos en un gráfico ampliable y pannable. La implementación actual, usando Protovis, es deficiente. Compruébalo aquí:
http://www.planethunters.org/classify
Hay aproximadamente 2000 puntos cuando se reduce el zoom por completo. Intente utilizar las asas en la parte inferior para acercar un poco y arrástrelo para desplazarse. Verás que está bastante agitado y que tu uso de CPU probablemente llegue al 100% en un núcleo, a menos que tengas una computadora realmente rápida. Cada cambio en el área de enfoque requiere un redibujado a protovis que es bastante lento y es peor con más puntos extraídos.
Me gustaría hacer algunas actualizaciones a la interfaz, así como cambiar la tecnología de visualización subyacente para que sea más receptiva con la animación y la interacción. En el siguiente artículo, parece que la elección es entre otra biblioteca basada en SVG o una basada en lienzo:
http://www.sitepoint.com/how-to-choose-between-canvas-and-svg/
d3.js , que surgió de Protovis, está basado en SVG y se supone que es mejor para renderizar animaciones . Sin embargo, dudo sobre cuánto mejor y cuál es su techo de rendimiento. Por esa razón, también estoy considerando una revisión más completa usando una biblioteca basada en lienzo como KineticJS . Sin embargo, antes de llegar demasiado lejos en el uso de un enfoque u otro, me gustaría saber de alguien que ha hecho una aplicación web similar con tantos datos y obtener su opinión.
Lo más importante es el rendimiento, con un enfoque secundario en la facilidad de agregar otras funciones de interacción y programar la animación. Probablemente no habrá más de 2000 puntos a la vez, con esas pequeñas barras de error en cada uno. Acercar, alejar y panoramizar debe ser fluido. Si las bibliotecas SVG más recientes son decentes en esto, entonces tal vez la facilidad de uso de d3 supere la configuración mejorada de KineticJS, etc. Pero si hay una gran ventaja de rendimiento al usar un lienzo, especialmente para personas con computadoras lentas, entonces Definitivamente preferiría ir por ese camino.
Ejemplo de una aplicación creada por el NYTimes que usa SVG, pero que aún se puede anotar de manera aceptable: http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html . Si puedo obtener ese rendimiento y no tener que escribir mi propio código de dibujo del lienzo, probablemente iré por SVG.
Noté que algunos usuarios han usado un híbrido de manipulación de d3.js combinado con renderizado de lienzo . Sin embargo, no puedo encontrar mucha documentación sobre esto en línea o entrar en contacto con el OP de esa publicación. Si alguien tiene alguna experiencia en este tipo de implementación DOM-to-Canvas ( demo , code ), me gustaría saber de usted también. Parece ser un buen híbrido de poder manipular datos y tener un control personalizado sobre cómo representarlo (y, por lo tanto, el rendimiento), pero me pregunto si tener que cargar todo en el DOM va a ralentizar las cosas.
Sé que hay algunas preguntas existentes que son similares a esta, pero ninguna de ellas pregunta exactamente lo mismo. Gracias por tu ayuda.
Seguimiento : la implementación que terminé usando está en https://github.com/zooniverse/LightCurves
Afortunadamente, dibujar círculos de 2000 es un ejemplo bastante fácil de probar. Aquí hay cuatro implementaciones posibles, dos de cada una de Canvas y SVG:
Estos ejemplos usan el comportamiento de zoom de D3 para implementar el zoom y la panorámica. Además de si los círculos se representan en Canvas o SVG, la otra distinción importante es si usa zoom geométrico o semántico .
El zoom geométrico significa que aplica una sola transformación a la ventana gráfica completa: cuando hace un acercamiento, los círculos se vuelven más grandes. El zoom semántico, en cambio, significa que aplica transformaciones a cada círculo individualmente: cuando hace un acercamiento, los círculos permanecen del mismo tamaño pero se extienden. Planethunters.org actualmente usa el enfoque semántico, pero podría ser útil considerar otros casos.
El zoom geométrico simplifica la implementación: aplica una traducción y escala una vez, y luego todos los círculos se vuelven a renderizar. La implementación de SVG es particularmente simple, actualizando un solo atributo de "transformación". El rendimiento de ambos ejemplos de acercamiento geométrico se siente más que adecuado. Para el acercamiento semántico, notará que D3 es significativamente más rápido que Protovis. Esto se debe a que está haciendo mucho menos trabajo para cada evento de zoom. (La versión de Protovis tiene que volver a calcular todos los atributos en todos los elementos). El zoom semántico basado en Canvas es un poco más rápido que SVG, pero el zoom semántico de SVG aún se siente receptivo.
Sin embargo, no existe una fórmula mágica para el rendimiento, y estos cuatro enfoques posibles no comienzan a cubrir todo el espacio de posibilidades. Por ejemplo, podría combinar el acercamiento geométrico y semántico, utilizando el enfoque geométrico para el paneo (actualizando el atributo "transformar") y solo redibujando círculos individuales al hacer zoom. Incluso podría combinar una o más de estas técnicas con transformaciones CSS3 para agregar algo de aceleración de hardware (como en el ejemplo de agrupamiento de bordes jerárquico ), aunque puede ser difícil de implementar y puede presentar artefactos visuales.
Aún así, mi preferencia personal es mantener tanto en SVG como sea posible, y usar Canvas solo para el "bucle interno" cuando el renderizado es el cuello de botella . SVG tiene tantas comodidades para el desarrollo, como CSS, uniones de datos y el inspector de elementos, que a menudo es una optimización prematura para comenzar con Canvas. Combinar Canvas con SVG, como en la visualización de IPO de Facebook que enlazó, es una forma flexible de conservar la mayoría de estas comodidades sin dejar de obtener el mejor rendimiento. También utilicé esta técnica en Cubism.js , donde el caso especial de la visualización de series de tiempo se presta bien al caché de mapa de bits.
Como muestran estos ejemplos, puede usar D3 con Canvas, aunque algunas partes de D3 son específicas de SVG. Ver también este gráfico dirigido a la fuerza y este ejemplo de detección de colisión .
Creo que en tu caso la decisión entre canvas y svg no es una decisión entre "montar un caballo" o conducir un "Porsche". Para mí, es más como la decisión sobre el color del automóvil.
Permítanme explicar: suponiendo que, en base al marco, las operaciones
- dibuja una estrella,
- agregar una estrella y
- eliminar una estrella
tomar tiempo lineal. Entonces, si su decisión sobre el marco fue buena, es un poco más rápida, de lo contrario, un poco más lenta.
Si continúas asumiendo que el marco es rápido, entonces se vuelve totalmente obvio que la falta de rendimiento es causada por la gran cantidad de estrellas y su manejo es algo que ninguno de los frameworks puede hacer por ti, al menos no lo sé sobre esto.
Lo que quiero decir es que la base del problema conduce a un problema básico de geometría computacional, a saber: búsqueda de rango y otra de gráficos de computadora: nivel de detalle .
Para resolver su problema de rendimiento necesita implementar un buen preprocesador que sea capaz de encontrar muy rápidamente qué estrellas mostrar y quizás pueda agrupar estrellas que están muy juntas, dependiendo del zoom. Lo único que mantiene viva y rápida tu vista es mantener el número de estrellas tan bajo como sea posible.
Como dijiste, lo más importante es el rendimiento, de lo que yo tendería a utilizar el lienzo, porque funciona sin operaciones DOM. También ofrece la oportunidad de usar webGL, lo que aumenta mucho el rendimiento gráfico.
Por cierto: ¿ paper.js ? Utiliza lienzo, pero emula gráficos vectoriales.
PD: en este libro puede encontrar una discusión muy detallada sobre los gráficos en la web, las tecnologías, los pros y los contras de canvas, SVG y DHTML.
Recientemente trabajé en un panel de control casi en tiempo real (actualización cada 5 segundos) y elegí usar gráficos que se procesan utilizando lienzo.
Probamos Highcharts (biblioteca de gráficos JavaScript basada en SVG) y CanvasJS (biblioteca de gráficos basados en Canvas). Aunque Highcharts es una fantástica API de gráficos y ofrece muchas más características, decidimos utilizar CanvasJS.
Necesitábamos mostrar al menos 15 minutos de datos por gráfico (con la opción de elegir un rango máximo de dos horas).
Por lo tanto, durante 15 minutos: 900 puntos (punto de datos por segundo) x2 (gráfico combinado de líneas y barras) x4 gráficos = 7200 puntos en total.
Utilizando el perfilador de Chrome, con CanvasJS la memoria nunca superó los 30 MB, mientras que con el uso de memoria de Highcharts superó los 600 MB.
También con un tiempo de actualización de 5 segundos, la representación de CanvasJS fue mucho más receptiva que Highcharts.
Usamos un temporizador (setInterval 5 segundos) para realizar 4 llamadas REST API para extraer los datos del servidor back-end que se conectó a Elasticsearch. Cada gráfico actualizado como datos es recibido por JQuery.post ().
Dicho esto, para los informes fuera de línea me gustaría ir con Highcharts ya que su API es más flexible.
También hay gráficos de Zing que dicen usar SVG o Canvas pero no los han mirado.
El lienzo debe considerarse cuando el rendimiento es realmente crítico. SVG por flexibilidad. No es que los frameworks de lienzo no sean flexibles, pero requiere mucho más trabajo para que Canvas Framework obtenga la misma funcionalidad que un framework svg.
También podría buscar Meteor Charts, que está construido sobre el súper rápido framework KineticJS: http://meteorcharts.com/