Pregunta

Tengo una aplicación MFC C ++ madura que se muestra en la pantalla e imprime utilizando envolturas CDC en el Win32 GDI. Si bien se ha optimizado a lo largo de los años, me gustaría reemplazarlo por algo un poco más rápido. Los gráficos incluyen modelos de superficie triangular renderizados, polilíneas y polígonos complejos y mucho texto. Debe cumplir con los siguientes criterios;

  • Es probable que la cantidad de vectores mostrados sea muy grande. Por ejemplo, es probable que un solo triángulo de superficie genere un número de líneas y rellenos sólidos cuando se procesa. En la actualidad, esta información no se almacena en ningún lugar, se genera y se extrae sobre la marcha. El SDK debe admitir limitar el número total de vectores almacenados en búfer, o puede quedarse sin memoria.

  • El SDK debería poder renderizar a cualquier clase derivada de CWnd, incluidas las clases CView y ScrollView.

  • El SDK debe admitir la impresión en cualquier dispositivo de impresión de Windows,

  • El SDK debe ser lo suficientemente bajo como para que el puerto de llamadas CDC / GDI de bajo nivel sea relativamente sencillo.

  • El código abierto siempre es bueno, pero un costo único de hasta $ 2k, con actualizaciones / soporte opcionales también estaría bien. No se acepta un costo de licencia por usuario,

  • El acceso al código fuente sería una gran ventaja, específicamente con la idea de ejecutar partes del SDK en Windows CE / Mobile.

  • Actualmente manejo mi propia gestión de ventana gráfica 3D a 2D. Si no hay disponible un SDK de nivel bajo decente, un SDK de nivel superior debe manejar bien 3d y trabajar con millones de triángulos, polígonos y entidades de texto en una plataforma de Windows de 32 bits.

¿Alguna sugerencia? Se agradecería enormemente enumerar los pros y los contras específicos en su sugerencia propuesta.

¿Fue útil?

Solución

Una vez he evaluado FastGraph ( http://www.fastgraph.com ) para un proyecto. Me gustó en los pequeños programas de prueba que escribí, fue muy rápido. Terminamos sin usarlo por razones externas (nada que ver con las bibliotecas que evalué) por lo que no tengo más experiencia práctica.

Otros consejos

Creo que DirectX o SDL se adaptarán a sus necesidades. Están diseñados para 3D pero también funcionan para 2D. Ambos admiten Windows CE / Mobile y SDL también está disponible para un conjunto de sistemas operativos que no son de Microsoft.

Desafortunadamente, la compatibilidad directa con GDI no es compatible con las bibliotecas. Pero puede hacer el truco creando una clase de convertidor, que aceptará todos los gráficos de salida de sus clases de aplicación diseñadas por GDI y convertirá el formato para que se ajuste a las necesidades de las clases DirectX o SDL (dependiendo de lo que quiera usar).

Personalmente hice esa clase de convertidor una vez. Tenía un juego escrito para Pocket PC, usando SDL y necesitaba portarlo al dispositivo Palm. Allí tuve que usar diferentes bibliotecas de gráficos (no recuerdo el nombre de la biblioteca ahora) pero logré portar todas las funciones de salida SDL al formato que necesita la otra biblioteca. Necesitaba cambiar mi aplicación para llamar a las funciones del convertidor (envoltorio), que reenvían la llamada a la biblioteca de Palm o Pocket PC, dependiendo del dispositivo que esté ejecutando actualmente. Así que creo que puedes hacer lo mismo para convertir GDI - > DirectX o GDI - > SDL.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top