Rendimiento de DrawingVisual frente a Canvas.OnRender para muchas formas en constante cambio

Question

Estoy trabajando en una aplicación similar a un juego que tiene hasta mil formas (elipsis y líneas) que cambian constantemente a 60 fps. Después de leer excellent article on rendering many moving shapes, implementé esto usando un descendiente personalizado de Canvas que reemplaza OnRender para hacer el dibujo a través de DrawingContext. El rendimiento es bastante razonable, aunque el uso de CPU se mantiene alto.

Sin embargo, el artículo sugiere que el enfoque más eficaz para constante movimiento formas es usar un montón de DrawingVisual casos en lugar de OnRender. Lamentablemente, aunque no explica por qué que debería ser más rápido para este escenario.

Cambiar la implementación de esta manera no es un esfuerzo pequeño, así que me gustaría entender las razones y si son aplicables a mí antes de decidir hacer el cambio. ¿Por qué podría el enfoque DrawingVisual dar como resultado un uso de CPU menor que el enfoque OnRender en este escenario?

Answer 1

Pensé que Petzold explica en este párrafo;

Los trabajos de clase ScatterPlotVisual por creación de un objeto DrawingVisual para cada DataPoint. Cuando cambian las propiedades de un objeto DataPoint, la clase solo necesita alterar el DrawingVisual asociado con ese DataPoint.

que se basa en la explicación anterior ;

Siempre que los ItemsSource propiedad cambios, o se cambia la colección, o una propiedad de los objetos DataPoint en los cambios de recolección, ScatterPlotRender llama InvalidateVisual. Esto genera una llamada a OnRender, que dibuja el diagrama de dispersión completo .

¿Es esto lo que preguntas? Por cierto, this es un tutorial WPF de alto rendimiento bastante reciente, con muchas decenas de miles de puntos en esa trama, también se representa en 3D y también se anima (incluso utiliza la entrada del mouse para controlar algunas de las transformadas).

Answer 2

De Pro WPF en C# 2008:

El problema planteado por estas aplicaciones no es la complejidad de el arte, pero el gran número de elementos gráficos individuales. Incluso si reemplaza sus elementos de ruta con objetos de Geometría más livianos, la sobrecarga aún obstaculizará el rendimiento de la aplicación . La solución WPF para este tipo de situación es para usar el modelo de capa visual de nivel inferior . La idea básica es que defina cada elemento gráfico como un objeto visual , que es un ingrediente ligero extremadamente que tiene menos sobrecarga que un objeto Geometry o un objeto Path.

Lo que se reduce a es que cada una de esas líneas y elipses que está creando es una FrameworkElement separada; eso significa que no solo es compatible con las pruebas de impacto, sino también con el diseño, la entrada, el enfoque, los eventos, los estilos, el enlace de datos, los recursos y la animación. ¡Es un objeto bastante pesado para lo que estás tratando de hacer! El objeto Visual omite todo eso y lo hereda directamente del DependencyObject. Todavía proporciona soporte para pruebas de golpes, transformación de coordenadas y cálculos de cuadro delimitador, pero ninguna de las otras cosas que admiten las formas. Es mucho más liviano y probablemente mejore tu rendimiento inmensamente.

EDIT:

Ok, leí mal su pregunta la primera vez.

En el caso de que esté usando OnRender, realmente depende de cómo está creando las imágenes y mostrándolas. Si está usando un DrawingContext y agrega todos los elementos visuales a un solo elemento, esto no es diferente de usar el enfoque DrawingVisual. Si estuviera creando un elemento separado para cada Visual creado, entonces esto sería un problema. Me parece que estás haciendo las cosas bien.

Answer 3

Todos en las respuestas se equivocaron. La pregunta es si renderizar figuras directamente en el contexto de dibujo es más rápido que crear DrawingVisual. La respuesta es obviamente sí'. Las funciones como DrawLine, DrawEllipse, DrawRectangle, etc. no crean ningún elemento UI. DrawingVisual es mucho más lento porque crea un elemento UI, aunque es liviano. La confusión en las respuestas se debe a que las personas simplemente copian/pegan el DrawingVisual tiene un mejor rendimiento que el enunciado de formas de UIElement distinto de MSDN.

Answer 4

En mis pruebas sin embargo (animaciones de barrido), noto que no hay diferencia en la velocidad. Diría que usar un elemento host para muchas imágenes de dibujo es un poco más rápido. Este enfoque donde construyes tu árbol visual con muchas imágenes te da más control. Además, cuando quiera realizar una prueba de impacto compleja, el proceso de filtrado es más rápido porque puede omitir "ramas" completas de imágenes