Rendimiento GDI en dispositivos Windows Mobile o CE

Question

Tengo una aplicación Windows CE que usa muchos gráficos vectoriales y en algunos lugares es bastante lenta. Actualmente estoy usando GDI para renderizar a través de un mapa de bits para actualizaciones sin parpadeo. Normalmente, estoy en una parte de un gran mapa 3d. En algunos dispositivos (por ejemplo, 166 mhz SH4), esto se hace lento con tiempos de actualización de 3-5 segundos para grandes conjuntos de datos. Mi pregunta es la siguiente:

• ¿Alguien ha hecho alguna comparación con la velocidad relativa de las operaciones gráficas en Windows Mobile frente a Win32? Dicho de otra manera, es perfilar los resultados de una versión Win32 del software aplicable a una versión WinCE, asumiendo que solo estamos buscando una llamada GDI.

• ¿Alguien ha intentado crear perfiles a bordo en una plataforma WinCE (aplicación C ++), en caso afirmativo, utilizando las herramientas?

• ¿Alguien conoce algún método para mejorar la velocidad de dibujo en Windows CE? Actualmente estoy viendo FastGraph siguiendo los comentarios de una pregunta anterior , Pero esta es una solución a largo plazo. Malo y todo como está, estoy buscando algo más rápido de implementar para una próxima versión.

Answer 1

Antes de Windows CE 6.0 (por lo tanto, incluye todas las versiones de Windows Mobile / Windows Embedded Handheld), el código de gráficos se implementó en otro proceso (GWES.EXE), que requiere una llamada de proceso cruzado cada vez que hace una llamada GDI. Las llamadas de proceso cruzado de CE 5.x son mucho más baratas que en el escritorio, pero aún más caras que una llamada de función simple o una llamada al modo kernel.

En el escritorio, GDI se implementa en modo kernel desde NT 4.0. En el NT 3.1 original, era como el modelo CE, llamadas de proceso cruzado. Para mitigar la sobrecarga de las llamadas de proceso cruzado o los interruptores de modo de usuario / kernel, GDI de escritorio agrupa las operaciones en el lado del modo de usuario hasta que haga algo que requiera que salga de la cola, como seleccionar un lápiz o pincel diferente, o usar uno de las funciones heredadas que devuelven algo que no sea BOOL , o el búfer está lleno, o lo vacías explícitamente llamando a GdiFlush .

Windows CE no tiene esta capacidad de procesamiento por lotes: todas las llamadas dan como resultado una llamada directa al proceso GWES, lo que lo hace mucho más lento. Puede mitigarlo haciendo el mayor trabajo posible en cada llamada. Si necesita una línea compleja, considere Polyline en lugar de llamadas individuales MoveToEx / LineTo. Intente tocar cada píxel una vez en lugar de representar objetos superpuestos, y utilice la región no válida para pintar solo partes de la pantalla que necesitan volver a pintarse (use GetUpdateRgn o GetUpdateRect pero hágalo antes de llamar a BeginPaint , que marca la región como válida).

El modelo de aceleración de gráficos CE es bastante básico y se basa en bit-blits. No es compatible con el conjunto más amplio de capacidades que admiten los controladores de dispositivos de escritorio del modelo Windows 2000. El hecho de que haya alguna aceleración disponible depende de si el hardware tiene incluso un chip acelerador; muchos dispositivos usarán el controlador LCD integrado en el procesador de la aplicación, que generalmente no hace ninguna aceleración.

Puede simular el comportamiento de CE en el escritorio deshabilitando el procesamiento por lotes, utilizando GdiSetBatchLimit para establecer el límite en 1. También considere usar el controlador de gráficos SVGA para deshabilitar la aceleración. En Windows Vista o Windows 7, GDI no se acelera si está utilizando el entorno Aero, todas las operaciones se implementan en el software, aunque Windows 7 agregó algunas nuevas capacidades de aceleración de hardware de blit de bits.

Windows CE 6.0 tiene un nuevo modelo de proceso y kernel, que mueve GDI al modo kernel como en el escritorio de Windows (antes de Vista), por lo que el costo de llamar a una función GDI debería reducirse ligeramente. Todavía no hay lotes.

Answer 2

No tengo mucho conocimiento del lado gráfico de las cosas, pero por experiencia, si quieres ser rápido en algunas cosas específicas relacionadas con el hardware, más cerca de " metal " Cuanto más rápido puedas llegar (y más difícil se vuelve!). Por lo tanto, puede considerar el uso de Direct Draw o Direct 3D (aunque creo que están eliminando D3D y pasando a OpenGL ES para WM7) . Es posible que desee ver cómo usan los Desarrolladores de juegos.

Sobre la cuestión de los perfiles, no he encontrado ninguno pero sí construyo mi own .

Answer 3

He hecho mucho de este tipo de evaluación comparativa, y las operaciones GDI son más lentas en WinCE que en Win32 normal, pero solo más lentas en proporción a los procesadores más lentos en dispositivos WinCE. En otras palabras, no parece haber ningún impacto de rendimiento adicional al usar GDI en WinCE.

Lo siento, no tengo respuestas a tus dos últimas preguntas.