wpf - control - uwp toolkit github

¿Hay una diferencia de rendimiento entre WPF y Winforms? (4)

El título lo dice todo. Hice algo de Google, pero la única información que puedo encontrar tiene al menos un año, parte de la información es más antigua que Windows 7. Así que, tengo curiosidad, ¿hay una penalización de rendimiento por usar WPF?

¿Funciona más rápido para algunas cosas (como el enlace de datos) que lo que tendrías que hackear juntos en WinForms?

Este será un proyecto creado con .NET, en caso de que eso le importe a alguien.

EDITAR

Este proyecto que estoy viendo tendría un estilo básico de UI, sin embargo, podría haber mucha información mostrada (está consultando archivos / directorios y mostrándolos en la pantalla). No he decidido si se actualizará automáticamente la pantalla, pero me imagino que puede.

Probablemente habrá una buena cantidad de controles, sin embargo, no hay nada que alguien deba considerar "gráfico" intensivo.

Estoy mirando el rendimiento y luego desde una perspectiva de aplicación empresarial.

NO planeo usar controles de terceros.

He codificado varias aplicaciones en el patrón MVVM tanto para Windows Forms como para WPF y cuando se compara la misma aplicación implementada en ambos, Windows Forms gana para aplicaciones enlazadas a datos. Notará el efecto más si tiene más de una cuadrícula de datos secundaria vinculada a una sola cuadrícula de datos o estructura principal, nunca entendió por qué. Así que para las aplicaciones empresariales, siempre codifico en WPF solo si tengo que hacerlo. También encuentro que la clasificación y el filtrado también son más fáciles en los formularios de Windows.

Intenté dibujar una gran cantidad de líneas en un panel en formas de victoria y el mismo dt en un lienzo en el uso de WPF y encontré que las formas de victoria crearon el arrastre en menos de un segundo, cuando WPF tardó muchos segundos, a pesar de que estaba usando la patometría en WPF en lugar de que shpes

No hay una respuesta significativa de "sí" o "no" a esto. Depende de muchos factores, que incluyen pero no se limitan a:

¿Qué tipo de interfaz de usuario está construyendo.
Obviamente, la complejidad de las vistas que está diseñando tendrá en cuenta el rendimiento en ambas plataformas. Tienen diferentes líneas de trazado y renderizado.
La eficacia con la que optimiza el rendimiento en cada plataforma.
Por supuesto, es fácil de implementar IU con bajo rendimiento en ambas plataformas. Implementar una IU compleja de tal forma que funcione muy bien requiere saber cómo aprovechar las fortalezas y debilidades de cada plataforma de manera efectiva.
Si está usando controles listos para usar o controles de terceros, y la calidad de esos controles.
Los artículos 1 y 2 se transfieren también a los componentes de terceros.

Si usted es un desarrollador experimentado y competente de WinForms, entonces probablemente ya sepa cómo crear vistas de rendimiento en WinForms. La curva de aprendizaje para WPF es empinada; cualquier desarrollador de WPF experimentado puede decírtelo. También le dirán que puede usarlo para crear interfaces de usuario enriquecidas que funcionen bien. Eso también es verdad. Lo mismo es cierto para WinForms.

Ambas plataformas están maduras. Ambos se utilizan ampliamente. Tampoco es probable que vea mejoras futuras, aparte de las correcciones de errores.

Dicho todo esto, si no está ya muy comprometido en ninguna de las plataformas, me gustaría seguir la ruta de WPF. Es un marco rico (aunque pesado) que se puede hacer para que funcione bien. La cantidad de esfuerzo necesario para que funcione bien depende en gran medida de los tipos de vistas que está creando, pero he creado muchas vistas de datos de alta frecuencia y gran volumen con WPF. También he construido un juego de estrategia visualmente rico con WPF. Pero no te sientas obligado a ir con eso; Si sus desarrolladores ya tienen experiencia con WinForms, sigue siendo una opción perfectamente viable.

Actualización: creo que es poco probable que el soporte de WinForms se elimine de .NET en los próximos años, pero si esto es una preocupación, entonces me gustaría ir a WPF. Los tipos de vistas que describe se pueden crear en WPF fácilmente. A modo de comparación, tengo varias vistas capaces de mostrar 50,000 a 500,000 filas con más de 60 columnas; miles de actualizaciones de fila por segundo; ordenación personalizada, multinivel y agrupación aplicada; filtrado personalizado; resúmenes personalizados; todo actualizado en tiempo pseudo en tiempo real (tiempo "humano" en tiempo real). Obtener ese nivel de rendimiento no fue fácil, pero se puede lograr. El volumen y la frecuencia de los datos que está describiendo deberían ser considerablemente más fáciles de lograr con cualquiera de las plataformas y utilizando solo el conjunto de control integrado.

Si estás haciendo UI complejas, WPF es el camino a seguir. Winforms no soporta nada.

Si estás haciendo UI simples, WPF es el camino a seguir, porque:

permite un patrón mucho más limpio (MVVM) en comparación con el horrible método de formas procesales de demasiado código para todo.
Tiene capacidades de enlace de datos mucho mayores.
Si alguna vez necesitas personalizar algo, puedes hacerlo.
Se ha incorporado en la virtualización de la interfaz de usuario .
Es la resolución independiente de forma predeterminada.

Si te preocupa el largo plazo:

WPF es el camino a seguir. El marco de la interfaz de usuario de Windows actual / futuro es WinRT XAML. Será MUCHO más fácil eventualmente portar su aplicación WPF a WinRT XAML que una aplicación de winforms. Y, dado que MVVM es realmente independiente de la tecnología, eventualmente podría reutilizar sus ViewModels en CUALQUIER otra tecnología de UI.

Edit: Ya que he estado recibiendo muchos comentarios negativos y hay mucha discusión en torno a esta respuesta, me centraré específicamente en la pregunta del OP y trataré de proporcionar una respuesta bastante objetiva:

Rendimiento: cuando se compara el uso de la memoria de WPF con las formas de ganancia para interfaces de usuario realmente simples (una Window o Form contiene solo un TextBox de TextBox por ejemplo), WPF parece consumir mucha más memoria que las formas de victoria. Esto se debe al hecho de que el marco de trabajo de WPF es mucho más grande que las plataformas de Windows y, por lo tanto, tiene muchas más "cosas para cargar" para poder funcionar. Esto también es cierto cuando se comparan los tiempos de arranque en frío (nuevamente, en una situación de 1 control).

En contraste, cuando creas UIs más pesadas compuestas por varios controles / Botones / DataGrids / ComboBoxes / TextBoxes / etc (cosas que son realmente comunes en las aplicaciones de negocios), la diferencia comienza a disminuir hasta que incluso favorece a WPF. Esto se debe a que el sistema DependencyProperty de WPF, que almacena los valores de propiedad predeterminados en un solo espacio de memoria en lugar de por instancia.

WPF fue pensado para ser utilizado para interfaces de usuario complejas / enriquecidas desde el principio y está optimizado para trabajar en situaciones donde hay miles de controles, en lugar del caso de 1-control.

Otro aspecto realmente importante a considerar cuando se compara el rendimiento entre WPF y Winforms desde una perspectiva centrada en los datos es, como se mencionó anteriormente, la virtualización de la interfaz de usuario . Con solo mirar este video , resulta obvio que WPF se desempeña mucho mejor en una situación en la que necesita mostrar 20k filas en un ListBox . Un gurú de winforms me dijo que los winforms también parecen respaldar eso, pero necesita recurrir a P / Invoke debido a que los winforms no lo soportan adecuadamente, y por lo que dijo no es obvio para mí si hay otros controles a un lado. del ListBox también es compatible con winforms (como DataGridView y TreeView ). TODOS los elementos de ItemsControls WPF ya están o pueden hacerse virtuales de forma predeterminada con algunos estilos simples de aplicación.

Aceleración de hardware: podría pensar "No necesito esto", pero si mira a su alrededor, hay miles de situaciones en las que las formas de victoria empezarán a parpadear horriblemente al actualizar la interfaz de usuario, no necesariamente en una situación de dibujo compleja, sino también al cambiar el tamaño de un Ventana que contiene muchos controles. Hay formas de solucionar esto, pero, de nuevo, tendría que comenzar a perder tiempo para solucionar un problema con el que nunca debería comenzar, en lugar de concentrarse en su lógica empresarial. NUNCA tendrá este problema con WPF, no solo porque es acelerado por hardware, sino también porque está basado en Vector, en lugar de en Bitmap.

Conclusión: si bien las formas de victoria pueden tener un mejor desempeño en el caso de 1-control, WPF es un claro ganador en todos los niveles para las IU de Datacéntrico del mundo real.

Aparte de todo esto, y como lo menciona @Blam, la elección de una tecnología requiere que analice no solo los aspectos de rendimiento, sino también la escalabilidad , la personalización , la facilidad de desarrollo , la perspectiva a largo plazo , entre muchas otras cosas.

En todos estos aspectos, WPF es nuevamente un claro ganador. una aplicación WPF MVVM bien diseñada tiene una base de código realmente limpia, concisa y hermosa. Winforms, no importa lo experto que sea con él, siempre lo forzará a tener un código sucio detrás de las soluciones, simplemente porque no admite escenarios realmente complejos y requiere un código personalizado para casi todo lo que se pueda imaginar.

En particular, con la personalización, diré que incluso si not planea crear una interfaz de usuario enriquecida y personalizada, la elección de WPF es una decisión mucho más sensata, ya que con las formas de ganancias puede llegar a una pared si alguna vez desea mostrar sus datos en un formato que no es compatible de forma predeterminada . Entonces tendrás que comenzar a sufrir y perder tu tiempo con técnicas horribles como "Dibujo de Propietarios", mientras que en WPF todo lo que necesitas es un DataTemplate simple.

Por supuesto, WPF es un marco complejo, pero no es realmente su complejidad lo que hace que la curva de aprendizaje sea tan pronunciada, sino que el cambio de mentalidad requerido es realmente lo que la mayoría de los desarrolladores que vienen de otros marcos luchan.

Y, como se mencionó anteriormente, es importante que codifique contra abstracciones, en lugar de contra un conjunto específico de clases, para que su código pueda ser portado a otros marcos si es necesario. WPF lo permite, Winforms no.

Si codificas en winforms, estarás atascado para siempre en las incapacidades de winforms y el código detrás de los hacks. Es cierto que si utiliza MVP en las plataformas con Windows esto se alivia un poco, pero los presentadores tienen un acoplamiento mucho más estrecho con el marco de la interfaz de usuario que ViewModels en MVVM, que es completamente independiente de la interfaz de usuario.

Si codificas en WPF con XAML y MVVM, eventualmente puedes reemplazar las vistas de WPF XAML por otra cosa, y mantener tus ViewModels intactos, lo que significa que en realidad NO tienes que volver a escribir tu aplicación completa desde cero, porque los ViewModels son la aplicación. no las vistas.