2008-09-16 16 views
12

Necesitamos optimizar el procesamiento de texto para una aplicación C# Windows Forms que muestra una gran cantidad de cadenas pequeñas en una cuadrícula irregular. En cualquier momento, puede haber más de 5000 células visibles que se actualizan 4 veces por segundo. La familia de fuentes y el tamaño son consistentes en todas las celdas, aunque el color puede variar de una celda a otra, al igual que en negrita/cursiva/normal.API más rápida para representar texto en formularios Windows Forms?

que he visto información contradictoria en la web sobre TextRenderer.DrawText vs Graphics.DrawString ser el más rápido/mejor, lo que reduce a un GDI vs GDI+ comparación a nivel Win32.

También he visto resultados radicalmente diferentes en Windows XP vs. Windows Vista, pero mi objetivo principal es Windows XP. Los artículos que prometen grandes avances bajo WinFX y DirectX 10 no son útiles aquí :-)

¿Cuál es el mejor enfoque aquí? No tengo miedo de introducir una pequeña capa de C++/CLI y optimizar el manejo del contexto del dispositivo para obtener más rendimiento, pero me gustaría obtener un consejo definitivo sobre qué dirección tomar.

EDIT: Gracias por las respuestas iniciales. Intentaré una combinación de renderizado de mapa de bits de fondo y apego a las llamadas equivalentes de GDI.

Respuesta

5

Un desarrollador de Microsoft ha publicado un artículo GDI vs. GDI+ Text Rendering Performance en su blog que responde a la pregunta de la velocidad bruta: en su sistema, GDI DrawText era aproximadamente 6 veces más rápido que GDI + DrawString.

Si necesitas ser un verdadero demonio de la velocidad, TextOut es más rápido que DrawText, pero tendrás que encargarse de los recortes y el ajuste de palabras tú mismo. ExtTextOut admite recorte.

La representación de GDI (TextRenderer) será más consistente con otras partes de Windows que usan GDI; GDI + intenta ser independiente del dispositivo y, por lo tanto, some spacing and emboldening are inconsistent. Consulte la herramienta Configuración de área de superficie de SQL Server 2005 para ver un ejemplo de representación incoherente.

+0

La aplicación de muestra en el enlace del blog es la que utilicé cuando vi la gran diferencia entre Vista y XP: en mi PC Vista, GDI y GDI + eran iguales, mientras que en XP veo la diferencia de 6x que menciona el autor. . Este es probablemente un problema con el controlador de Vista, pero resalta algunas de las dificultades aquí, ¡gracias! –

+1

Nota histórica: ExtTextOut solía ser la forma más rápida de dibujar un rectángulo sólido en algunas tarjetas/controladores :) –

2

GDI es más rápido en el dibujo en general que GDI +. Trabajé en un proyecto que tenía que dibujar miles de líneas y cadenas de texto y cambiar de GDI + a GDI hizo una mejora significativa en el rendimiento. Eso fue usando Windows XP, así que no puedo comentar sobre Vista. También recomendaría usar doble buffering para que tu dibujo también mejore el rendimiento. Cree un mapa de bits compatible fuera de pantalla y vuelva a utilizarlo cada vez que necesite dibujar.

3

5000+ la reproducción de texto es lenta incluso con GDI, especialmente si necesita desplazarse. Cree un subproceso de representación por separado y notifique el subproceso de interfaz de usuario cada 200 ms y bitblt los resultados actuales. Da una experiencia de usuario sin problemas.

2

Crear una clase de interoperabilidad C++/CLI para hacer el dibujo en código nativo resultará en un dibujo increíblemente rápido. Hemos sido testigos de esto y lo hemos medido.

Si no está haciendo eso, hemos encontrado gráficos. DrawString es solo un poco más rápido que TextRenderer.DrawText.

2

En mi sistema Windows 7 64 Bit ¡TextOut es incluso un poco más lento que DrawString! TextRenderer.DrawText es mucho más lento que DrawString.

+1

¡También descubrí esto ... pero no encuentro ningún motivo !? – series0ne

Cuestiones relacionadas