¿En qué orden son los paneles los más eficientes en términos de tiempo de renderizado y rendimiento?


Hay muchas veces 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 renderizado para diferentes tipos de panel.

Por ejemplo, MSDN establece que

Un Panel relativamente simple, como Canvas, puede tener significativamente mejor rendimiento que un Panel más complejo, como Grid.

Entonces, en términos de tiempo de renderizado y rendimiento, en qué orden están los paneles WPF más eficiente?

Paneles 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 encontrarla ahora.

La respuesta ideal que estoy buscando me proporcionaría una lista de paneles en el orden en que lo harían más rápido. Entiendo que el número de niños es un factor importante en la eficiencia de los paneles, así que para el bien de esta pregunta, supongamos que cada panel solo tiene un Label/TextBox par.

Además, me gustaría una lista de excepciones, tales como paneles específicos que funcionan mejor que otros basados en ciertas condiciones.

Update

Para resumir basado en 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, un VirtualizingPanel / VirtualizingStackPanel siempre debe usarse si hay muchos elementos que no siempre caben en la pantalla.

Le recomiendo encarecidamente que lea la respuesta aceptada a continuación para obtener más detalles antes de elegir un elemento de esta lista.

Author: Community, 2012-03-30

3 answers

Creo que es más conciso y comprensible describir las características de desempeño de cada panel que tratar de dar una comparación de desempeño relativa absoluta.

WPF hace dos pasadas al renderizar contenido: Medir y Organizar. Cada panel tiene diferentes características de rendimiento para cada una de estas dos pasadas.

El rendimiento del paso de medida se ve más afectado por la capacidad de un panel para acomodar el estiramiento utilizando alineaciones (o Auto en el caso de la Grid) y luego el número de hijos que se estiran o auto-tamaño. El rendimiento del pase Arrange se ve afectado por la complejidad de la interacción entre la ubicación del diseño de diferentes niños y, por supuesto, el número de niños.

A veces 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 posicionara en un cierto porcentaje del espacio disponible. Ninguno de los predeterminados los controles hacen esto. Intentar que hagan esto (a través del enlace al tamaño real del padre) resulta en un rendimiento horrible. Creé un panel de diseño basado en el Lienzo que logró el resultado deseado con un trabajo mínimo (copié la fuente del lienzo y modificé alrededor de 20 líneas del mismo).

Paneles disponibles:

  • Canvas

    Define un área dentro de la cual se puede posicionar explícitamente hijo elementos por coordenadas relativas a el área del Lienzo.

    El Lienzo tiene el mejor rendimiento de todos los paneles para el pase de disposición, ya que a cada elemento se le asigna una ubicación estática. El measure pass también tiene un excelente rendimiento ya que no hay ningún concepto de estiramiento en este panel; cada niño simplemente usa su tamaño nativo.

  • DockPanel

    Define un área dentro de la cual puede organizar elementos secundarios horizontal o verticalmente, en relación con cada otro.

    El Dockpanel tiene un esquema de diseño muy simple donde 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 nativo del elemento (basado en la Parte Superior/Inferior vs Izquierda/Derecha respectivamente) y la otra dirección está determinada por la propiedad Dock si el ancho o el alto no están definidos. Paso de medida medio a rápido y paso de disposición medio a rápido.

  • Grid

    Define un área de cuadrícula flexible que consiste en columnas y filas.

    Este puede ser el panel más intensivo de rendimiento si se usa dimensionamiento proporcional o auto dimensionamiento. Calcular el tamaño del elemento secundario 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 arreglo pasar.

  • StackPanel

    Organiza los elementos secundarios en una sola línea que puede ser orientada horizontal o verticalmente.

    El StackPanel mide sus hijos usando el tamaño nativo o relativo en la dirección opuesta a su orientación y el 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 acuerdo es simplemente, solo poner los artículos en orden. Probablemente la segunda mejor actuación para este pase. Rendimiento medio para el pase de medición y rendimiento rápido para el pase de diseño.

  • VirtualizingPanel

    Proporciona un marco para los elementos del panel que virtualizan su recopilación de datos hijo. Esta 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 procesador. Mucho más rendimiento para conjuntos de elementos. Probablemente un poco menos de rendimiento para los elementos que caben en la pantalla debido a la comprobación de límites. El SDK solo proporciona una subclase de esto, la VirtualizingStackPanel.

  • WrapPanel

    Coloca los elementos secundarios en posición secuencial de izquierda a derecha, rompiendo el contenido a la siguiente línea en el borde de la caja contenedora. El orden posterior se produce secuencialmente de arriba a abajo o de derecha a izquierda, dependiendo sobre el valor de la Propiedad de orientación.

    El paso de medida es un paso algo complejo donde el elemento más grande de 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 diseño es simple, colocando cada elemento uno tras otro en una fila y luego continuando en la siguiente fila cuando no hay suficiente espacio para el siguiente elemento. Paso medio de la medida del funcionamiento. Medio a rápido rendimiento para el pase de acuerdo.

Referencias:

Utilice el Panel más Eficiente cuando sea Posible

La complejidad del proceso de maquetación se basa directamente en la maquetación comportamiento de los elementos derivados del panel que utiliza. Por ejemplo, una Cuadrícula o StackPanel control proporciona mucha más funcionalidad que un lienzo control. El precio de este mayor aumento en la funcionalidad es un mayor aumento de los costes de rendimiento. Sin embargo, si no se requieren la funcionalidad que proporciona un control de cuadrícula, debe utilizar el alternativas menos costosas, como un lienzo o un panel personalizado.

De Optimización del Rendimiento: Maquetación y Diseño

El sistema de diseño completa dos pases para cada miembro de los Hijos colección, un pase de medida y un pase de disposición. Cada Panel infantil proporciona sus propios métodos MeasureOverride y ArrangeOverride para lograr su propio diseño específico comportamiento.

Durante el pase de medida, cada miembro de la colección de Niños es evaluar. El proceso comienza con una llamada al método Measure. Este método se llama dentro de la implementación del Panel padre elemento, y no tiene que ser llamado explícitamente para ocurrir.

Primero, se evalúan las propiedades de tamaño nativo del UIElement, como Clip y Visibilidad. Esto genera un valor llamado constraintSize que se pasa a MeasureCore.

En segundo lugar, las propiedades del marco definidas en FrameworkElement son procesado, que afecta al valor de constraintSize. Estas propiedades describir generalmente las características de dimensionamiento del subyacente UIElement, como su Altura, Ancho, Margen y Estilo. Cada uno de estos propiedades pueden cambiar el espacio que es necesario para mostrar el elemento. MeasureOverride se llama entonces con constraintSize como un parámetro.

Nota Hay una diferencia entre las propiedades de Altura y Anchura y ActualHeight y ActualWidth. Por ejemplo, la altura actual propiedad es un valor calculado basado en otras entradas de altura y la sistema de diseño. El valor es establecido por el propio sistema de diseño, basado en un pase de renderizado real, y por lo tanto puede retrasarse ligeramente establecer el valor de las propiedades, como la Altura, que son la base de la cambio de entrada. Debido a que ActualHeight es un valor calculado, usted debe tenga en cuenta que podría haber informes múltiples o incrementales cambio a él como resultado de diversas operaciones por el sistema de diseño. El el sistema de diseño puede estar calculando el espacio de medida requerido para el niño elementos, restricciones por el elemento padre, y así sucesivamente. El último el objetivo del pase de medida es que el niño determine su DesiredSize, que se produce durante la llamada a MeasureCore. El tamaño deseado el valor se almacena por Medida para su uso durante el pase de disposición de contenido.

El pase arrange comienza con una llamada al método Arrange. Durante el arrange pass, el elemento del panel padre genera un rectángulo que representa los límites del niño. Este valor se pasa a la Método ArrangeCore para el procesamiento.

El método ArrangeCore evalúa el DesiredSize del hijo y evalúa cualquier margen adicional que pueda afectar el tamaño de elemento. ArrangeCore genera un arrangeSize, que se pasa a el método ArrangeOverride del Panel como parámetro. ArrangeOverride genera el Tamaño final del niño. Por último, el El método ArrangeCore realiza una evaluación final de las propiedades de desplazamiento, tales como margen y alineación, y pone al hijo dentro de su ranura de diseño. El niño no tiene que (y con frecuencia no) llenar todo el espacio asignado. Control se devuelve entonces al Panel padre y el proceso de diseño se ha completado.

De Midiendo y Arreglando a los Niños

 104
Author: mydogisbox,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-09-18 11:33:53

Tal vez esto te ayudará.
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 dirigirse.

 11
Author: mike_sev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-06 14:32:11

Los paneles que mencionas son paneles de diseño, por lo que una breve descripción general del sistema de diseño sugiere que es probable que no sea solo una simple lista del panel más eficiente, sino cómo se utilizan los paneles que tienen el mayor efecto en la eficiencia y el rendimiento.

LayoutSystem_Overview :

En su forma más simple, el layout es un sistema recursivo que conduce a que un elemento sea dimensionado, posicionado y dibujado. Más específicamente, el diseño describe el proceso de medición y organizar los miembros de la colección Infantil de un elemento de panel. El diseño es un proceso intensivo. Cuanto mayor sea la colección de Niños, mayor será el número de cálculos que se deben hacer. La complejidad también se puede introducir en función del comportamiento de diseño definido por el elemento 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 elemento secundario cambia su posición, tiene el potencial de desencadenar un nuevo pase por el sistema de diseño. Por lo tanto, es importante comprender los eventos que pueden invocar el sistema de diseño, ya que la invocación innecesaria puede conducir a un rendimiento deficiente de la aplicación. A continuación se describe el proceso que se produce cuando se invoca el sistema layout.

1. Un UIElement hijo comienza el proceso de diseño midiendo primero sus propiedades principales.

2. Se evalúan las propiedades de dimensionamiento definidas en FrameworkElement, tales como Anchura, Altura y Margen.

3. Se aplica una lógica específica del panel, como la dirección del muelle o la orientación del apilamiento.

4. El contenido se organiza después de que todos los niños hayan sido medidos.

5. La colección de niños se dibuja en la pantalla.

6. El proceso se invoca de nuevo si se agregan hijos adicionales a la colección, se aplica una LayoutTransform o se llama al método UpdateLayout.

Ver LayoutSystem_Measure_Arrange para más información sobre la medición y organización de los niños

LayoutSystem_Performance :

El layout es un proceso recursivo. Cada elemento secundario de una colección secundaria se procesa durante cada invocación del sistema de diseño. Como resultado, se debe evitar activar el sistema de diseño cuando no sea necesario. Las siguientes consideraciones pueden ayudarle a lograr un mejor rendimiento.

Tenga en cuenta qué cambios de valor de propiedad forzarán una actualización recursiva por parte del diseño sistema.

Las propiedades de dependencia cuyos valores pueden causar que el sistema de diseño se inicialice se marcan con banderas públicas. AffectsMeasure y AffectsArrange proporcionan pistas útiles sobre qué cambios de valor de propiedad 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 true. Para obtener más información, consulte Descripción general de propiedades de dependencias.

Cuando sea posible, utilice un RenderTransform en lugar de 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 usar una 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 layout para dar cuenta de la nueva posición del afectado elemento.

Evite llamadas innecesarias a UpdateLayout.

El método UpdateLayout fuerza una actualización recursiva del layout, y frecuentemente 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 a este método por usted.

Cuando trabaje con una colección Infantil grande, considere usar un VirtualizingStackPanel en lugar de un StackPanel normal.

Al virtualizar la colección hija, el VirtualizingStackPanel solo mantiene los objetos en memoria que se encuentran actualmente dentro de la ventana principal. 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 entra en detalles sobre cómo construir el árbol de manera eficiente y da una lista simple de paneles basados en su complejidad

Canvas (menos complext = más eficiente y mejor rendimiento)

Grid

Otros paneles (más complejo = menos eficiente y peor rendimiento)

Otras consideraciones de rendimiento a las que prestar atención: Formas de mejorar la velocidad de renderizado de la interfaz de usuario de WPF

  1. Guarda todo en caché. Pinceles, Colores, Geometrías, Textos Formateados, Glifos. (Por ejemplo, tenemos dos clases: RenderTools y TextCache. El proceso de renderizado de cada unidad se dirige a una instancia compartida de ambas clases. Así que si dos gráficos tienen el mismo texto, su preparación se ejecuta una sola vez.)
  2. Freeze Freezable, si está planeando para usarlo durante mucho tiempo. Especialmente geometrías. Las geometrías complejas no congeladas ejecutan hitTest extremadamente lento.
  3. Elige las formas más rápidas de renderizar cada primitiva. Por ejemplo, hay alrededor de 6 formas de renderizar texto, pero la más rápida es dibujar contenido.DrawGlyphs.
  4. Permitir El Reciclado De Contenedores. La virtualización trae muchas mejoras de rendimiento, pero los contenedores se eliminarán y se volverán a crear, este es el valor predeterminado. Pero puede obtener más rendimiento reciclando contenedores configurando VirtualizingStackPanel.VirtualizationMode="Recycling"
  5. De aquí: No hay un límite práctico a la cantidad de anidamiento que su aplicación puede soportar, sin embargo, generalmente es mejor limitar su aplicación para usar solo los paneles que son realmente necesarios para su diseño deseado. En muchos casos, se puede usar un elemento de cuadrícula en lugar de paneles anidados debido a su flexibilidad como contenedor de diseño. Esto puede aumentar el rendimiento de su aplicación al mantener los elementos innecesarios fuera del árbol.
 7
Author: Erick,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:10:02