2008-10-13 15 views
8

He oído que las primitivas WPF no serán compatibles con el escritorio remoto en Windows XP. La consecuencia de esto es que si ejecuta una aplicación WPF en una máquina de vista y la muestra en una máquina de XP (a través de un escritorio remoto) la pantalla se enviará como un mapa de bits comprimido.¿Hay problemas con la representación de WPF a través de Escritorio remoto en Windows XP?

Este problema se resuelve en la comunicación Vista-Vista a través de DirectX 11 (?) Pero esto no estará disponible en XP. Obviamente, hay un rendimiento aquí, me gustaría entenderlo antes de incursionar en el desarrollo de aplicaciones para WPF.

la información sobre este tema se puede encontrar aquí:

http://blogs.msdn.com/tims/archive/2007/01/05/comparing-wpf-on-windows-vista-v-windows-xp.aspx

Ver comentario del enlace de arriba (cita):


A la pregunta del SpongeJim, esto se hace mediante la MIL (capa de integración de medios), que es el núcleo subyacente de WPF que maneja la composición. En una conexión de escritorio remota Vista/Vista, las primitivas MIL se remotan y luego se reconstituyen. En otras combinaciones (por ejemplo, 2003/XP), lo que se remueve son los mapas de bits, que obviamente requieren mucho más ancho de banda. Más a fondo sobre este tema se puede encontrar en el blog de Greg Schechter, y en esta entrada en particular: http://blogs.msdn.com/greg_schechter/archive/2006/06/09/623566.aspx


¿alguien tiene alguna experiencia o más al día la información sobre este tema?

Respuesta

6

A partir de .NET 3.5 SP1, todos los gráficos WPF son remotos como mapas de bits, incluso en la comunicación Vista-a-Vista. De http://blogs.msdn.com/jgoldb/archive/2008/05/15/what-s-new-for-performance-in-wpf-in-net-3-5-sp1.aspx:

Ahora somos remotos como mapas de bits en TODOS los casos.

La razón es que WPF 3.5 SP1 ahora utiliza un nuevo archivo DLL de gráficos (wpfgfx.dll) y ciertos cambios no se podía hacer a los gráficos existentes de Vista DLL (milcore.dll) que también es utilizado por DWM .

Como han señalado otros comentadores, el rendimiento dependerá en gran medida del diseño de la interfaz de usuario de su aplicación.El resultado potencial es que solo tienes que probar en un escenario; el rendimiento de comunicación remota ahora debería ser el mismo independientemente del cliente o servidor.

0

supongo que esto depende de su aplicación wpf. si tiene muchos degradados, animaciones, pinceles, etc. ... definitivamente su aplicación se ejecutará más despacio ...

+0

Bueno, pero hay una gran diferencia entre remoting los primativos y la reconstrucción de una pantalla y remoting un mapa de bits comprimido! –

2

No hemos tenido problemas al utilizar Remote Admin y Bomgar para la comunicación remota una vez que esas aplicaciones se actualizaron para trabajar con WPF. Probamos XP a XP, XP a Vista, Vista a XP y Vista a Vista. Inicialmente, solo habíamos tenido problemas con la información sobre herramientas y las ventanas emergentes/pop-ups desplegables. Durante los últimos seis meses más o menos, las cosas han estado bien.

Acabo de probar la comunicación remota en una Vista VM desde mi escritorio XP y nuestra aplicación se veía genial (si funciona un poco lento, pero es una VM ...) Cambié a color de 8 bits de baja calidad y los problemas de rendimiento casi se fue por completo. La graduación, etc., se perdió en el fondo de nuestra ventana, etc., pero definitivamente todavía era utilizable.

No creo que deba tener ningún problema funcional, y solo problemas menores de rendimiento.

Cuestiones relacionadas