Aumento del rendimiento de gráficos gráficos con altas velocidades de datos

Question

Me gustaría crear gráficos de líneas con miles de puntos que se actualizan por completo al menos 10 veces por segundo. ¿Cuáles son algunas técnicas para aumentar el rendimiento de los gráficos con una gran cantidad de datos para mostrar?

Una idea que he tenido es cambiar el número de llamadas de sorteo a partir de la cantidad de puntos de datos a la cantidad de píxeles disponibles. Podría dividir los datos en contenedores a lo largo del eje X y dibujar una línea vertical entre el mínimo y el máximo para cada contenedor.

Answer 1

No es un buen artículo acerca de representar el rendimiento más en el blog Visiblox, here.

Puede que no esté utilizando esta biblioteca de gráficos particular en su aplicación, pero los puntos principales del artículo todavía se aplicarán. Se trata de seleccionar cuidadosamente lo que necesita para mostrar cuándo. Los puntos principales del artículo son:

• considerar cuidadosamente el tipo de serie de usar
• Donde sea posible conjunto rangos explícitos en los ejes
• Retire los puntos que están fuera de la pantalla de the DataSeries
• Eliminar la generación de datos de la interfaz de usuario hilo
• reducir o animaciones desactivar
• pensar cuidadosamente acerca de la cantidad de datos y la frecuencia de cambios

También hay un artículo un poco menos útil en la MSDN blog, pero debería ayudar a delinear algunas de las áreas clave al mejorar el rendimiento del gráfico.

Answer 2

En términos generales se podría hacer coule de las cosas:

• actualizaciones Delta. Solo vuelve a dibujar los bits del gráfico donde los datos han cambiado. Podría, por ejemplo, simplemente traducir los píxeles en el gráfico a la izquierda y solo dibujar los datos frescos en lugar de volver a dibujar todo.
• Datos de muestra. Como describes, tus datos pueden ser tan densos que no sea significativo dibujar cada punto. Según el nivel de zoom para el gráfico, puede soltar algunos de los puntos de datos.
• Redibujar según la velocidad de fotogramas del dispositivo, no la velocidad de datos. No tiene sentido volver a dibujar el gráfico más rápido de lo que se puede mostrar, no poner en cola otro redibujado si ya hay uno en progreso. Hacer eso puede obstruir la cola de mensajes de la que depende la mayoría de los usuarios de la interfaz de usuario y dar como resultado un tartamudeo ui.

Un buen truco por cierto es dibujar una línea vectorial con algunos puntos que representarán la resolución de su gráfico [cantidad de píxeles horizontales, por ejemplo], luego puede tener los datos 'moverse' vector de puntos en la línea como una cola, donde cambiaría los elementos 'a la izquierda' antes de agregar un nuevo punto de datos. En términos Wpf, esto dará como resultado un gráfico 'virtualizado', lo que significa que el elemento ui es una instancia constante y animada en lugar de volver a instanciarse cuando ingresen datos nuevos.

Un ejemplo opuesto sería agregar un nuevo línea vectorial entre el último punto y el nuevo punto cuando hay nuevos datos disponibles. (Supongo que se utiliza una API de alto nivel donde las líneas/formas son objetos discretos, si no, la 'virtualización' no es realmente aplicable)

Answer 3

¿Es realmente necesaria una resolución tan alta o es realmente? solo usado para cálculos internos. es posible que pueda hacer un promedio interno/compresión de los puntos antes de llamar a su función de dibujo para que tenga menos puntos.

Answer 4

Si el que necesita tener un buen rendimiento durante la manipulación del usuario, se puede hacer lo siguiente:

1. Cuando los usuarios se inicia una interacción con el gráfico, cree una versión simplificada de la misma, digamos en el máximo 30 los puntos de datos estarían presentes en esa tabla.
2. que el usuario acabe su manipulación

3. diagrama de relleno con todos los puntos de datos (que podría utilizar un algoritmo de muestreo aquí también, ya que no tiene sentido para hacer más puntos que la resolución de la pantalla)

   Al usar ese enfoque tu gráfico será muy sensible mientras se lo manipula (aunque con menos detalles) y detallado mientras estático.

Answer 5

Revelación: Me propio software ABT y estuvo directamente involucrado en el desarrollo de SciChart

Por desgracia hay gráfico basado en WPF usando la tubería del modo de gráficos retenido es capaz de hacer frente a escenarios de alta tasa de datos. Como resultado, he creado un componente de gráfico WPF/SL de alto rendimiento llamado SciChart para hacer frente a este tipo de situaciones. SciChart busca llenar el vacío para gráficos científicos/de inventario de alto rendimiento y, como parte de su optimización, utiliza algoritmos de remuestreo exclusivos para reducir el conjunto de datos antes de dibujar.

En respuesta a su pregunta, le sugiero que eche un vistazo a la teoría Nyquist Frequency (que se utiliza en el procesamiento de señales digitales). Esto indica que el número mínimo de puntos de datos necesarios para discretizar con precisión una forma de onda es 2 veces la frecuencia de muestreo. En el caso de una señal de audio, por ejemplo, una frecuencia de muestreo de 44 kHz (para CD de audio) puede representar con precisión una frecuencia máxima de Fs/2 o 22 kHz. En el caso de un gráfico, la frecuencia de Nyquist es de 2x píxeles de ancho; este es el número mínimo de puntos de datos necesarios para discretizar con precisión las frecuencias hasta e incluyendo el ancho del píxel.

Tenga en cuenta que este es un mínimo y experimentará aliasing. Para evitar esto, o necesita un antialiasing filter antes de la etapa de remuestreo y/o necesita mayores múltiplos de puntos.

Los algoritmos de remuestreo son bastante conocidos y las implementaciones rápidas están disponibles. Sugeriría remuestrear a múltiplos de su ancho de píxel y aplicar AA para obtener los mejores resultados.