2009-04-21 6 views
1

Je suis à la recherche de technologies pour un nouveau produit embarqué doté d'un processeur via 1 ghz et d'une puce graphique via s3. Jusqu'à présent, la plate-forme cible est Linux, mais souhaiterait pouvoir la déplacer vers une plate-forme Windows. L'application comprendrait des widgets comme des boutons, des graphiques et des affichages numériques/textuels. Plus important encore, l'application contient des objets animés, tels que les fans en rotation constante. Qt semblait être un bon choix, car il est multi-plateforme et a une API sympa pour un tas de widgets et un cadre d'animation.Qt meilleur choix pour l'animation sur embarqué?

Cependant, cette structure d'animation utilise assez fortement le processeur. L'utilisation du processeur cible pour le rendu de l'interface utilisateur est de 40%. La rotation de 25 objets avec une image nécessite environ 90% de CPU.

L'idée est d'utiliser opengl pour animer les objets et enlever cette lourde charge de la CPU.

Ma question est, si Qt le meilleur choix pour quelque chose comme ça? Dois-je regarder plus en profondeur quelque chose comme Java 2D?

+0

Votre animation est-elle 2D ou 3D? – DJClayworth

+2

Vous savez que Qt vous permet d'héberger des animations OpenGL dans ses fenêtres? Peut-être que vous pourriez faire les choses sensibles au CPU dans OpenGL et laisser le reste à Qt. –

Répondre

0

Le principal argument de vente de Qt est qu'il s'agit d'une boîte à outils graphique multiplateforme, ce qui est une fonctionnalité intéressante, mais que Java a déjà. Vous pouvez préférer la version de Qt, et beaucoup de gens le font, mais ne l'utilisez pas simplement parce qu'elle est multi-plateforme. This article montre que le framework d'animation Qt n'est pas encore intégré dans Qt.

Si vous pouvez programmer dans GL alors JOGL est un point de départ évident, mais si vous ne pouvez pas être conscient que la programmation GL n'est pas facile. Vous pourriez également envisager Java3D. Peut-être que ce que vous voulez peut être fait dans JavaFX.

1

pour autant que je me souvienne, le cadre d'animation de Qt peut être utilisé pour l'animation continue, mais est probablement pas le meilleur choix pour tel. Je pense que c'était plus conçu pour les animations transitoires, comme faire glisser un widget, ou développer/réduire les choses. Je regarderais soit en utilisant OpenGL ou éventuellement QGraphicsView, ce qui vous permet de faire un dessin plus direct. En outre, si vous regardez autour de vous, vous devriez pouvoir trouver des instructions pour dire à Qt d'utiliser OpenGL ou OpenGL ES comme backend pour le système de rendu, ce qui devrait réduire le nombre d'accès à votre processeur (en supposant que vous utilisiez OpenGL ou OpenGL ES). ne l'ai pas déjà fait).

1

Vous devez profiler votre application pour vraiment découvrir ce qui ne va pas. Par exemple, une forme fixe mais un élément graphique en rotation continue peut bénéficier beaucoup du cache de coordonnées d'élément (voir QGraphicsItem::setCacheMode). De même, les images fixes doivent être mises en cache et conservées le plus longtemps possible sous forme de pixmaps. La profondeur de couleur peut également jouer un rôle important. Les éléments graphiques complexes basés sur le chemin doivent être simplifiés autant que possible.

En résumé, il existe de nombreuses raisons pour lesquelles les performances graphiques sont mauvaises. Sans les élaborer et les attaquer un par un, le passage à OpenGL ne résoudra pas vraiment le problème.Cela pourrait accélérer le frame-by-second (en raison de l'avantage évident de transférer certaines responsabilités au matériel graphique), mais ceci est un avantage à court terme et diminue rapidement à long terme si le vrai problème n'est pas découvert.

+0

Que recommandez-vous pour le profilage? Une recherche rapide suggère Valgrind, mais cela ne fonctionne que sur Linux. Y at-il une option qui fonctionnerait à la fois sur Linux et sur Windows? – Dutch

Questions connexes