Devo sviluppare un'applicazione per Windows che consenta di controllare il mouse attraverso la web cam riconoscendo i gesti delle mani. Userò vC++ 2008 per lo sviluppo. Ma sono confuso se andare con .NET framework o core win32 API. Le prestazioni sono molto importanti per la mia applicazione. Come per il libro "Beginning Visual C++ 2008" di Ivor Horton, vi è una leggera penalizzazione delle prestazioni associata all'uso di .NET Framework. Volevo sapere su quali fattori dipende la penalità e sarà possibile utilizzare .NET framework per la mia applicazione.scelta tra API win32 e .NET framework
risposta
Se si conosce l'API Win32, quindi fare clic su API Win32. È la scelta naturale nel tuo caso poiché la maggior parte del tuo codice sorgente sarà l'acquisizione di video, l'elaborazione delle immagini, gli algoritmi e le interfacce per il mouse in Windows. Quando sei interessato alle prestazioni, sii vicino all'hardware evitando strati spessi come .NET.
Credo che .NET sia per applicazioni aziendali complesse non per applicazioni in tempo reale o driver di periferica.
Un modo rapido per dirlo: la differenza di prestazioni tra l'API nativa e .Net può essere compensata acquistando un processore più costoso. Pagheresti da qualche parte tra $ 1 e $ 100 in più, con $ 10 che sono una stima ragionevole - per CPU ovviamente. Pertanto, se prevedi più di un milione di utenti, scegli l'API nativa. Se pensate di usarlo su 2-3 PC demo, non ha alcuna importanza.
Non sono d'accordo con questo. Acquistando un processore più costoso si ottengono prestazioni, ma non si compensa la differenza tra API native e .Net. Sul processore più veloce la differenza di prestazioni tra l'API nativa e .Net sarà la stessa. L'acquisto di un processore più veloce oggi per risolvere il tuo problema di prestazioni non garantisce che sarai in grado di risolvere il tuo problema di prestazioni domani. – Patrick
La domanda è: quali prestazioni sono necessarie per l'applicazione. In questo caso, non è il punto per ottenere il massimo delle prestazioni. C'è un limite sulla web cam, USB e l'utente per riconoscerlo. – dyp
Suppongo che si potrebbe anche dire di spendere di più per lo sviluppo. Uno sviluppatore scarso in Win32 scriverà un'applicazione lenta e noiosa che può essere eseguita molte volte più lentamente rispetto a uno sviluppatore di prim'ordine che utilizza .NET. – Brain2000
.NET è utile per le GUI e per la programmazione generale in aree non ad alte prestazioni. Se devi fare qualcosa di più di una semplice GUI, ti suggerirei di scrivere almeno quella parte in un linguaggio .NET.
In quello che hai descritto del tuo programma, riconoscere i gesti delle mani sarà l'unica parte computazionalmente intensiva. L'effettivo processo di controllo del mouse è banale. Quindi, fintanto che la parte di riconoscimento dei gesti funziona abbastanza bene per le tue esigenze, probabilmente non importa quale sia il resto del programma.
Primo passo, dovresti cercare quali librerie sono là fuori che fanno il riconoscimento dei gesti o elaborazione di immagini simili. (Spero che tu non abbia intenzione di scrivere quella parte da zero comunque.) Se trovi delle librerie basate su .NET che dichiarano di avere prestazioni abbastanza buone per le tue esigenze, allora potresti provare. Altrimenti, avresti probabilmente una libreria basata su C o C++ o simili. In ogni caso, è possibile integrare una cosa del genere con un programma basato su .NET.
Penso che si dovrebbe limitare l'utilizzo di .NET per la costruzione della GUI. Il resto delle opere tenta di fare in Win32. Restituita la domanda sul riconoscimento degli oggetti, esiste una bella libreria chiamata OPENCV (open source Computer Vision Library). questa lib contiene tutti i metodi possibili che si richiedono nel progetto. Inoltre, la libreria hardware specifica di Intel, IPP, migliora le prestazioni di Opencv.
A meno che non si sia un molto esperto C++, programmatore, C# è un linguaggio molto più produttivo (parlando come qualcuno con oltre 15 anni di esperienza C++ e 2 anni C#).
Le librerie .Net offrono una vasta gamma di funzionalità di alta qualità più facili da usare rispetto alla libreria standard C++.
Quindi, vorrei usare .Net.
Si consiglia inoltre di utilizzare C++/CLI per chiamare direttamente complesse librerie native se è necessario integrarle, anziché P/Invoke. Questo va bene per le chiamate dispari ma non ti consente di accedere facilmente alle strutture di dati o di mischiare codice nativo e gestito.
- 1. scelta tra Stream e collezioni API
- 2. StructureMap e ASP .Net Web API e .Net Framework 4.5
- 3. Creazione di menu di scelta rapida per Win32 API
- 4. Differenza tra .NET Framework 4.6, Net Nativi e .Net Nucleo
- 5. Chiamate API Mocking e Win32
- 6. Scelta tra Prisma e Caliburn
- 7. Ruby interfaccia win32 api
- 8. Scelta tra MEF e MAF (System.AddIn)
- 9. std :: unique_ptr, deleters e API Win32
- 10. Tasto rapido globale con API WIN32?
- 11. Win32 API FindFirstFile e FindNextFile prestazioni vs riga di comando
- 12. Scelta tra GDC e DMD
- 13. Scelta tra FileReader e InputStreamReader
- 14. scelta tra $ 0 e BASH_SOURCE
- 15. Buona o cattiva - API Win32 SetParent() tra diversi processi
- 16. Passa alla compilazione tra framework compatto e completo .net?
- 17. Documentazione C++ Win32 API offline?
- 18. .NET Entity Framework e transazioni
- 19. .NET framework compatto e ActiveSync
- 20. .net Framework Error (HRESULT 0x8007000B)
- 21. API Win32 chiamata Errore GetShortPathName in F #
- 22. La scelta di utilizzare .Net 4
- 23. Scelta tra std :: map e std :: unordered_map
- 24. Scelta tra CharSequence e String per un'API
- 25. Framework NLP per .NET
- 26. Domain Driven Design, .NET e Entity Framework
- 27. Differenza tra ASP.NET Core (.NET Core) e ASP.NET Core (.NET Framework)
- 28. Come utilizzare le API win32 con python?
- 29. Win32 API analogico di invio/cattura SIGTERM
- 30. Come uscire dall'applicazione Win32 tramite API?
Puoi quantificare un po 'le "prestazioni"? cioè quale frame rate hai bisogno? .. ecc. Solo con queste informazioni puoi prendere una decisione consapevole * ("tempo reale" non è una buona risposta). *. – Rusty