Tengo que desarrollar una aplicación para Windows que permita controlar el mouse a través de la cámara web mediante el reconocimiento de gestos con las manos. Utilizaré vC++ 2008 para el desarrollo. Pero estoy confundido sobre si ir con .NET framework o núcleo de win32 API. El rendimiento es muy importante para mi aplicación. Según el libro "Beginning Visual C++ 2008" de Ivor Horton, hay una pequeña penalización de rendimiento asociada al uso de .NET framework. Quería saber de qué factores depende la penalización y si será factible utilizar .NET framework para mi aplicación.elección entre win32 API y .NET framework
Respuesta
Si está familiarizado con la API de Win32, vaya a la API de Win32. Es la opción natural en su caso, ya que la mayoría de su código fuente será captura de video, procesamiento de imágenes, algoritmos e interfaces para mouse en Windows. Cuando esté interesado en el rendimiento, esté más cerca del hardware evitando capas gruesas como .NET.
Creo que .NET es para aplicaciones de negocio complejas no para aplicaciones en tiempo real o controladores de dispositivos.
Una forma rápida de decirlo: la diferencia de rendimiento entre la API nativa y .Net se puede compensar comprando un procesador más caro. Pagaría en algún lugar entre $ 1 y $ 100 más, siendo $ 10 una estimación razonable, por CPU, por supuesto. Entonces, si espera más de un millón de usuarios, elija la API nativa. Si espera usarlo en las PC demo de 2 o 3, realmente no importa en absoluto.
No estoy de acuerdo con esto. Al comprar un procesador más caro, obtiene rendimiento, pero no compensa la diferencia entre API nativa y .Net. En el procesador más rápido, la diferencia de rendimiento entre la API nativa y .Net será la misma. Comprar un procesador más rápido hoy para resolver su problema de rendimiento no garantiza que mañana pueda solucionar su problema de rendimiento. – Patrick
La pregunta es, ¿qué rendimiento necesita para su aplicación? En este caso, no es el punto para obtener el máximo rendimiento. Hay un límite en la cámara web, USB y el usuario para reconocerlo. – dyp
Supongo que también podría decirse que gasta más en desarrollo. Un desarrollador deficiente en Win32 escribirá una aplicación lenta y tediosa que puede correr muchas veces más lenta en comparación con un desarrollador de primera clase que usa .NET. – Brain2000
.NET es bueno para GUI y para la programación general en áreas que no requieren un alto rendimiento. Si necesita hacer algo más que una GUI trivial, le sugiero que escriba al menos esa parte en un lenguaje .NET.
En lo que ha descrito de su programa, reconocer los gestos con las manos va a ser la única parte computacionalmente intensiva. El proceso real de controlar el mouse es trivial. Así que mientras la parte de reconocimiento de gestos funcione lo suficientemente bien para sus necesidades, probablemente no importará en qué está escrito el resto del programa.
Primer paso, debe investigar qué bibliotecas hay por ahí que reconocen gestos o procesamiento de imágenes similar. (Espero que no tenga la intención de escribir esa parte desde cero de todos modos.) Si encuentra alguna biblioteca basada en .NET que afirme tener un rendimiento lo suficientemente bueno para sus necesidades, entonces podría intentarlo. De lo contrario, probablemente terminarías con una biblioteca basada en C o C++ o similar. De cualquier manera, sin embargo, es posible integrar tal cosa con un programa basado en .NET.
Creo que debe limitar el uso de .NET para la construcción de GUI. Lo mejor de lo que se intenta hacer es hacer en Win32. Pregunta restante sobre el reconocimiento de objetos, hay una bonita biblioteca llamada OPENCV (biblioteca de visión por ordenador de código abierto). esta lib contiene todos los métodos posibles que necesitarías en el proyecto. También está la biblioteca específica de hardware de Intel, IPP, que aumenta el rendimiento de Opencv.
A menos que usted es un muy experimentaron C++, programador, C# es un lenguaje mucho más productivo (hablando como alguien con más de 15 años de experiencia en C++ y C# 2 años).
Las bibliotecas .Net ofrecen una gran cantidad de funcionalidades de alta calidad que son más fáciles de usar que la biblioteca C++ estándar.
Entonces, yo usaría .Net.
También recomiendo usar C++/CLI para llamar directamente a bibliotecas nativas complejas si tiene que integrarlas, en lugar de P/Invoke. Eso es bueno para llamadas impares, pero no le permite acceder fácilmente a estructuras de datos o mezclar código nativo y administrado.
- 1. La elección entre WPF, wxWidgets, API Win32 y MFC
- 2. StructureMap y ASP .Net Web API y .Net Framework 4.5
- 3. Elección de .Net 4
- 4. Diferencia entre ASP.NET y .NET framework versión
- 5. Diferencia entre PathAppend y PathCombine en Win32 API
- 6. Dynamic LINQ API con .NET Framework 4
- 7. Llamadas de API de Mocking y Win32
- 8. Gui's con Win32 API
- 9. Ruby win32 api interface
- 10. diferencia entre #if defined (WIN32) y #ifdef (WIN32)
- 11. Cómo convertir entre zonas horarias con API win32?
- 12. ¿Compilación de conmutadores entre .NET Framework compacto y completo?
- 13. penetración de .NET framework entre usuarios domésticos?
- 14. .NET Entity Framework y transacciones
- 15. Diferencia entre las [...] API asincrónicas Async y Begin [...] .NET
- 16. .NET compact framework y ActiveSync
- 17. Google Analytics API y .Net
- 18. Creando una tabla usando Win32 API
- 19. Win32 API GetShortPathName llamada error en Fa #
- 20. Domain Driven Design, .NET y Entity Framework
- 21. C# sin .NET Framework
- 22. diferencia entre API y marco
- 23. ¿Cómo crear hilos con Win32 API?
- 24. Actualizando el orden Z de muchas ventanas usando Win32 API
- 25. Cómo hacer varias ventanas usando Win32 API
- 26. Win32 API analógica de envío/captura SIGTERM
- 27. ¿Cómo matar procesos por nombre? (Win32 API)
- 28. C++ Win32 API documentación fuera de línea?
- 29. RESTful Zend Framework API
- 30. Win32 pila API caminar con MinGW/MSYS?
¿Se puede cuantificar un poco el "rendimiento"? es decir, ¿qué tasa de cuadros necesita? ... etc. Solo con esta información puede tomar una decisión informada * ("en tiempo real" no es una buena respuesta). *. – Rusty