2011-09-23 6 views
7

OK, enfrentémoslo, durante el renderizado y un pase de diseño, la IU de WPF se congelará ...¿Previene la congelación durante la reconstrucción de la IU compleja de WPF?

¿Escapa de esto?

Alguien habló sobre la serialización y la desregistración de XAML, pero ¿realmente funciona? Todo lo que veo es un lapso momentáneo y una ventana congelada para interfaces de usuario complejas que están deserializadas.

¿Alguna vez podré lograr una carga de UI rápida?

P.S. No estoy hablando de cargar datos de vista en el hilo de fondo y esas cosas. De todos modos, es una norma hoy en día. Pero ¿hay CUALQUIER (esto debería sonar desesperado) forma de no producir una ventana colgada para interfaces de usuario complejas? Por complejo me refiero a estilos pesados, plantillas profundamente jerárquicas, paneles no virtualizados, etc.

+1

¿Lo obtienes solo en Visual Studio? Para mí, Visual Studio se cuelga algunas veces, pero el .exe es bastante sólido. Visual Studio SP1 ayudó mucho. Una máquina multiprocesador también ayuda. Para mí, parece colgar construyendo el árbol visual algunas veces. Si el XAML tiene un nombre de enlace no válido, parece que se obtiene más cuelga. Pero si lo dejo reposar de 1 a 5 minutos, funciona. El 90% del tiempo se cargará en 2-5 segundos. Nunca salgo en páginas en un proyecto que no estoy usando. – Paparazzi

+0

¿Qué hay de usar la clase Dispatcher con la baja prioridad 'Background'? – vorrtex

+0

hmmm ... probablemente estoy tan desesperado porque odio admitir que me parece que las formas de ganar no se cuelgan para interfaces de usuario complejas (dejando de lado la carga de datos). :( –

Respuesta

2

Dada la fábula de su pregunta, usted está esperando una respuesta de Rob Relyea al menos (no estoy seguro de si todavía está). Ojalá tengamos una propiedad PreventFreezing, puesta por alguien con cierto descuido en falso. Pero no lo somos Creo que la única manera de ver el problema es mirarlo en cada caso. Algunos frameworks, es decir, prism y alikes sipmly, no están diseñados para admitir una ejecución sin problemas, y están claramente establecidos en la descripción.

Después de más de 5 años de tratar con WPF/SL, todavía tengo la sensación de que todos estamos trabajando con un prototipo, bien diseñado, pero que sigue siendo un prototipo. Muchas cosas están diseñadas muy bien, pero diseñadas para nunca cumplir con las fechas límite de rendimiento.

Creo que 'Agregar futuros sin preocuparnos demasiado por cualquier otra cosa' es una etapa muy natural en el ciclo de vida de cualquier proyecto de gran envergadura. Durante esta etapa, el número de futuros crece expotencialmente, por lo que la deuda técnica sí lo hace. Todo esto es bueno siempre y cuando siga el pago técnico de la deuda, lo que no parece suceder con WPF, es decir, revisión de rendimiento, revisión de usabilidad de sintaxis y más.

+0

* Editado * comentario en el lugar equivocado - lo siento –

+0

Sí, WPF definitivamente todavía se siente como una prueba de concepto bastante detallada en lugar de un marco pulido terminado. –

Cuestiones relacionadas