wpf - ¿En qué orden son los paneles los más eficientes en términos de tiempo de renderizado y rendimiento?
performance rendering (3)
Creo que es más conciso y comprensible describir las características de rendimiento de cada panel que tratar de ofrecer una comparación de rendimiento relativa absoluta.
WPF realiza dos pasadas al representar contenido: Medir y Organizar. Cada panel tiene diferentes características de rendimiento para cada uno de estos dos pases.
El rendimiento del paso de la medida se ve más afectado por la capacidad de un panel para acomodar el estiramiento utilizando alineaciones (o Automático en el caso de la Grid
) y luego el número de niños que se estiran o se dimensionan automáticamente. El rendimiento del pase Organizar se ve afectado por la complejidad de la interacción entre la ubicación del diseño de diferentes niños y luego, por supuesto, la cantidad de niños.
En ocasiones, los paneles dados no se prestan fácilmente al diseño necesario. Creé un control que necesitaba un número arbitrario de elementos para que cada uno se posicione en un determinado porcentaje del espacio disponible. Ninguno de los controles predeterminados hace esto. Intentar hacer que lo hagan (mediante el enlace con el tamaño real del elemento principal) produce un rendimiento horrible. Creé un panel de diseño basado en el lienzo que logró el resultado deseado con un mínimo de trabajo (copié el origen del lienzo y lo modifiqué en torno a 20 líneas).
Paneles disponibles:
Lona
Define un área dentro de la cual puedes posicionar explícitamente elementos secundarios por coordenadas relativas al área del Lienzo.
El lienzo tiene el mejor rendimiento de todos los paneles para el pase de arreglos, ya que cada elemento tiene una ubicación estáticamente asignada. El pase de la medida también tiene un excelente rendimiento ya que no existe el concepto de estiramiento en este panel; cada niño simplemente usa su tamaño original.
DockPanel
Define un área dentro de la cual puede organizar los elementos secundarios, ya sea horizontal o verticalmente, uno con relación al otro.
El Dockpanel tiene un esquema de distribución muy simple en el que los elementos se agregan uno por uno en relación con el elemento anterior agregado. De forma predeterminada, la altura o el ancho están determinados por el tamaño original del elemento (basado en Superior / Inferior vs Izquierda / Derecha respectivamente) y la otra dirección está determinada por la propiedad
Dock
si el ancho o alto no está definido. Pase de medición de medio a rápido y pase de disposición de medio a rápido.Cuadrícula
Define un área de cuadrícula flexible que consta de columnas y filas.
Este puede ser el panel con mayor rendimiento si se utiliza el tamaño proporcional o el tamaño automático. El cálculo del tamaño del elemento hijo puede ser una combinación compleja del tamaño nativo del elemento y el diseño especificado por la cuadrícula. El diseño es también el más complicado de todos los paneles. Rendimiento lento a medio para el paso de medida y rendimiento lento a medio para el pase de acuerdo.
StackPanel
Organiza elementos secundarios en una sola línea que se puede orientar horizontal o verticalmente.
El StackPanel mide a sus hijos usando tamaños nativos o relativos en la dirección opuesta a su orientación y tamaño nativo en la dirección de su orientación (la alineación no hace nada en esta dirección). Esto lo convierte en un intérprete de nivel medio en esta área. El pase de Arreglo es simple, simplemente presentando los elementos en orden. Probablemente el segundo mejor rendimiento para este pase. Rendimiento medio para el paso de medida y el rendimiento rápido para el pase de disposición.
VirtualizingPanel
Proporciona un marco para los elementos del Panel que virtualizan su colección de datos secundarios. Esto es una clase abstracta.
Una clase base para implementar su propio panel de virtualización. Solo carga elementos visibles para evitar el uso innecesario de la memoria y el procesador. Mucho más rendimiento para conjuntos de artículos. Probablemente sea un poco menos eficiente para los artículos que se ajustan a la pantalla debido a la verificación de límites. El SDK solo proporciona una subclase de esto,
VirtualizingStackPanel
.WrapPanel
Posiciona elementos secundarios en posición secuencial de izquierda a derecha, rompiendo el contenido en la siguiente línea en el borde del cuadro contenedor. Los pedidos posteriores se realizan de forma secuencial de arriba a abajo o de derecha a izquierda, según el valor de la propiedad de Orientación.
El pase de la medida es un pase algo complejo donde el elemento más grande para una fila en particular determina la altura de la fila y luego cada elemento en esa fila usa su altura nativa (si tiene una) o la altura de la fila. El pase de disposición es simple, colocando cada elemento uno detrás de otro en una fila y luego continuando en la siguiente fila cuando no hay espacio suficiente para el siguiente artículo. Pase de medida de rendimiento medio. Rendimiento medio a rápido para el pase de acuerdo.
Referencias
Utilice el panel más eficiente donde sea posible
La complejidad del proceso de disposición se basa directamente en el comportamiento de disposición de los elementos derivados del Panel que utiliza. Por ejemplo, un control Grid o StackPanel proporciona mucha más funcionalidad que un control Canvas. El precio de este mayor aumento en la funcionalidad es un mayor aumento en los costos de rendimiento. Sin embargo, si no requiere la funcionalidad que proporciona un control Grid, debe usar las alternativas menos costosas, como un lienzo o un panel personalizado.
De optimizar el rendimiento: diseño y diseño
El sistema de disposición completa dos pases para cada miembro de la colección Children, un pase de medida y un pase de organización. Cada panel secundario proporciona sus propios métodos MeasureOverride y ArrangeOverride para lograr su propio comportamiento de diseño específico.
Durante el pase de la medida, se evalúa cada miembro de la colección Children. El proceso comienza con una llamada al método de Medida. Este método se llama dentro de la implementación del elemento del Panel padre, y no tiene que ser llamado explícitamente para que ocurra el diseño.
Primero, se evalúan las propiedades de tamaño nativo del UIElement, como Clip y Visibility. Esto genera un valor llamado constraintSize que se pasa a MeasureCore.
En segundo lugar, se procesan las propiedades del marco definidas en FrameworkElement, lo que afecta el valor de constraintSize. Estas propiedades generalmente describen las características de tamaño del elemento UIE subyacente, como su altura, ancho, margen y estilo. Cada una de estas propiedades puede cambiar el espacio que es necesario para mostrar el elemento. A continuación, se llama a MeasureOverride con constraintSize como parámetro.
Nota Hay una diferencia entre las propiedades de Alto y ancho y ActualHeight y ActualWidth. Por ejemplo, la propiedad ActualHeight es un valor calculado basado en otras entradas de altura y el sistema de disposición. El valor es establecido por el propio sistema de disposición, basado en un pase de renderizado real, y por lo tanto puede quedar un poco por detrás del valor establecido de las propiedades, como Altura, que son la base del cambio de entrada. Debido a que ActualHeight es un valor calculado, debe tener en cuenta que podría haber cambios informados múltiples o incrementales como resultado de varias operaciones realizadas por el sistema de diseño. El sistema de disposición puede calcular el espacio de medida requerido para elementos secundarios, las restricciones del elemento principal, etc. El objetivo final del pase de medición es que el niño determine su Tamaño deseado, que se produce durante la llamada MeasureCore. El valor DesiredSize es almacenado por Measure para su uso durante el pase de organización de contenido.
El pase de arreglos comienza con una llamada al método Arrange. Durante el pase de organización, el elemento del Panel padre genera un rectángulo que representa los límites del niño. Este valor se pasa al método ArrangeCore para su procesamiento.
El método ArrangeCore evalúa el tamaño deseado del niño y evalúa cualquier margen adicional que pueda afectar el tamaño representado del elemento. ArrangeCore genera un arrangeSize, que se pasa al método ArrangeOverride del Panel como parámetro. ArrangeOverride genera el tamaño final del niño. Finalmente, el método ArrangeCore realiza una evaluación final de las propiedades de compensación, como el margen y la alineación, y coloca al niño dentro de su ranura de disposición. El niño no tiene que (y con frecuencia no) llenar todo el espacio asignado. El control se devuelve al Panel padre y el proceso de diseño se completa.
Hay muchas ocasiones en que más de un panel sería adecuado para el diseño que quiero, sin embargo, sé que hay una diferencia en los tiempos de procesamiento para diferentes tipos de paneles.
Por ejemplo, MSDN afirma que
Un
Panel
relativamente simple, comoCanvas
, puede tener un rendimiento significativamente mejor que unPanel
más complejo, comoGrid
.
Entonces, en términos de tiempo de renderización y rendimiento, ¿en qué orden los paneles WPF son los más eficientes?
Paneles de WPF:
-
Canvas
-
DockPanel
-
Grid
-
UniformGrid
-
StackPanel
-
WrapPanel
-
VirtualizingPanel
/VirtualizingStackPanel
Estoy bastante seguro de que vi una lista de esto en algún lugar en línea, pero no puedo encontrarlo ahora.
La respuesta ideal que estoy buscando me proporcionaría una lista de paneles en el orden en que rendirían más rápido. Entiendo que el número de niños es un factor importante en la eficiencia de los paneles, por lo tanto, por el bien de esta pregunta, supongamos que cada panel solo tiene un par de Label
/ TextBox
.
Además, quisiera una lista de excepciones, como paneles específicos que funcionan mejor que otros según ciertas condiciones.
Actualizar
Para resumir en función de la respuesta aceptada a continuación, el rendimiento del panel se basa en el número y el diseño de los elementos secundarios, sin embargo, en general, la lista de más rápido a más lento es:
-
Canvas
-
StackPanel
-
WrapPanel
-
DockPanel
-
Grid
Además, siempre se debe usar VirtualizingPanel
/ VirtualizingStackPanel
si hay muchos elementos que no siempre caben en la pantalla.
Le recomiendo que lea la respuesta aceptada a continuación para obtener más detalles antes de simplemente elegir un elemento de esta lista.
Los paneles que menciona son paneles de diseño por lo que una breve descripción general del sistema de diseño sugiere que probablemente no sea una simple lista del panel más eficiente, sino cómo utilizar los paneles que tienen el mayor efecto en la eficiencia y el rendimiento.
En su forma más simple, el diseño es un sistema recursivo que conduce a un elemento que se dimensiona, coloca y dibuja. Más específicamente, el diseño describe el proceso de medición y organización de los miembros de la colección Children de un elemento del Panel. El diseño es un proceso intensivo. Cuanto mayor sea la colección de Children, mayor será el número de cálculos que se deben realizar. La complejidad también se puede introducir en función del comportamiento de diseño definido por el elemento del Panel que posee la colección. Un Panel relativamente simple, como Canvas, puede tener un rendimiento significativamente mejor que un Panel más complejo, como Grid.
Cada vez que un UIElement infantil cambia su posición, tiene el potencial de activar un nuevo pase por el sistema de disposición. Por lo tanto, es importante comprender los eventos que pueden invocar el sistema de disposición, ya que la invocación innecesaria puede conducir a un rendimiento de aplicación deficiente. A continuación, se describe el proceso que se produce cuando se invoca el sistema de disposición.
1. Un UIElement hijo comienza el proceso de disposición midiendo primero sus propiedades centrales.
2. Se evalúan las propiedades de tamaño definidas en FrameworkElement, como Ancho, Alto y Margen.
3. Se aplica lógica específica del panel, como dirección de la base o orientación de apilamiento.
4. El contenido se organiza después de que todos los niños han sido medidos.
5. La colección Children se dibuja en la pantalla.
6. El proceso se invoca nuevamente si se agregan niños adicionales a la colección, se aplica un LayoutTransform o se llama al método UpdateLayout.
Consulte LayoutSystem_Measure_Arrange para obtener más información sobre la medición y organización de los niños
El diseño es un proceso recursivo. Cada elemento secundario de una colección de Children se procesa durante cada invocación del sistema de diseño. Como resultado, se debe evitar activar el sistema de disposición cuando no sea necesario. Las siguientes consideraciones pueden ayudarlo a lograr un mejor rendimiento.
Tenga en cuenta qué cambios en el valor de la propiedad obligarán a una actualización recursiva por parte del sistema de diseño.
Las propiedades de dependencia cuyos valores pueden causar que el sistema de disposición se inicialice se marcan con banderas públicas. AffectsMeasure y AffectsArrange proporcionan pistas útiles sobre los cambios en el valor de la propiedad que forzarán una actualización recursiva por parte del sistema de diseño. En general, cualquier propiedad que pueda afectar el tamaño del cuadro delimitador de un elemento debe tener un indicador AffectsMeasure establecido en verdadero. Para obtener más información, vea Información general sobre las propiedades de dependencia.
Cuando sea posible, use un RenderTransform en lugar de un LayoutTransform.
Un LayoutTransform puede ser una forma muy útil de afectar el contenido de una interfaz de usuario (UI). Sin embargo, si el efecto de la transformación no tiene que afectar la posición de otros elementos, es mejor utilizar RenderTransform en su lugar, porque RenderTransform no invoca el sistema de diseño. LayoutTransform aplica su transformación y fuerza una actualización recursiva del diseño para tener en cuenta la nueva posición del elemento afectado.
Evite llamadas innecesarias a UpdateLayout.
El método UpdateLayout obliga a una actualización recursiva del diseño, y con frecuencia no es necesario. A menos que esté seguro de que se requiere una actualización completa, confíe en el sistema de diseño para llamar este método por usted.
Cuando trabaje con una colección grande para niños, considere usar un VirtualizingStackPanel en lugar de un StackPanel normal.
Al virtualizar la colección secundaria, VirtualizingStackPanel solo mantiene objetos en la memoria que se encuentran actualmente dentro del ViewPort del padre. Como resultado, el rendimiento se mejora sustancialmente en la mayoría de los escenarios.
Optimización del rendimiento: diseño y diseño : este artículo detalla cómo construir el árbol de manera eficiente y ofrece una lista simple de paneles en función de su complejidad.
Lienzo (menos completo = más eficiente y mejor rendimiento)
Cuadrícula
Otros paneles (más complejo = menos eficiente y peor rendimiento)
Otras consideraciones de rendimiento para prestar atención a: Formas de mejorar la velocidad de renderización de la interfaz de usuario WPF
- Guarda todo Pinceles, colores, geometrías, textos formateados, glifos. (Por ejemplo, tenemos dos clases: RenderTools y TextCache. El proceso de representación de cada unidad se dirige a la instancia compartida de ambas clases. De modo que si dos gráficos tienen el mismo texto, su preparación se ejecuta solo una vez).
- Congelar Freezable, si planea usarlo por un largo tiempo. Especialmente geometrías. Las geometrías complejas sin congelar ejecutan HitTest extremadamente lento.
- Elija las formas más rápidas de representación de cada primitiva. Por ejemplo, hay alrededor de 6 formas de representación de texto, pero la más rápida es DrawingContext.DrawGlyphs.
- Habilitar el Reciclaje de Contenedores. La virtualización aporta muchas mejoras de rendimiento, pero los contenedores se eliminarán y volverán a crearse, este es el valor predeterminado. Pero puede obtener más rendimiento reciclando contenedores configurando VirtualizingStackPanel.VirtualizationMode = "Recycling"
- Desde here : no existe un límite práctico para la cantidad de anidamiento que su aplicación puede admitir, sin embargo, generalmente es mejor limitar su aplicación para que solo use los paneles que realmente son necesarios para su diseño deseado. En muchos casos, se puede usar un elemento Grid en lugar de paneles anidados debido a su flexibilidad como contenedor de diseño. Esto puede aumentar el rendimiento en su aplicación al mantener los elementos innecesarios fuera del árbol.
Quizás this te ayude.
No solo para paneles sino también para cada aplicación que desee hacer en WPF.
Concluye el rendimiento de dibujo y medición de WPF.
También tiene una aplicación de prueba de dibujo, resultados e información de conclusiones para diferentes sistemas operativos a los que desea apuntar.