Je développe une application très simple pour la plate-forme Mac OSX en utilisant Qt et OpenGL (et QtOpenGL) afin que la plateforme croisée soit plus facile.
L'application reçoit un nombre variable de flux vidéo qui doivent être rendus à l'écran. Chaque image de ces flux vidéo est utilisée comme texture pour mapper un rectangle dans un espace 3D (très similaire à une mosaïque vidéo). En dehors des choses telles que la réception, le verrouillage, le téléchargement de données vidéo, la synchronisation de threads ... je considère qu'il est clair que c'est une application assez simple.Le même code QtOpenGL s'exécute environ 15 fois plus lentement en passant à Carbon (vs Cocoa)
Le fait est que tout se comporte bien lorsqu'on utilise des binaires Qt 4.7 à base de cacao (ceux par défaut) dans un Mac 10.5. Mais mon code doit fonctionner correctement sur toutes les versions d'OSX à partir de (et y compris vers) 10.4. J'ai donc essayé le code dans une machine 10.4 et il s'est écrasé juste au démarrage. Après quelques heures de lecture sur Internet, j'ai découvert que pour qu'une application Qt soit ciblée à 10,4, il faut utiliser une base de carbone Qt. Donc, je reconstruis l'ensemble du projet avec le nouveau cadre.
Lorsque le nouveau binaire résultant est exécuté, tout fonctionne bien, sauf que les fps de l'application tombent à environ 2 fps !! Et il se comporte de la même manière sur les deux machines (l'ordinateur 10.5 a sensiblement les meilleures caractéristiques) J'ai passé beaucoup de temps à travailler dessus mais je n'ai pas encore trouvé de solution. Tout suggérer?
Plus d'informations sur l'application et les choses que j'ai essayé
-
Code
- n'a pas été modifié lors d'une recompilation carbone à base
- seulement deux (256x256 textures) vidéos ar utilisées pour assurer que ce n'est pas une bande passante problème limite (même si je sais que ce ne devrait pas parce que le premier code travaillé)
- les 2 flux vidéo arrivent de réseau (local)
- lorsqu'un flux vidéo arrive, un signal est exprimés et les données seront téléchargées sur un Texture OpenGL (glTexSubImage2 D)
- une minuterie rend le rendu (paintGL) à environ 20 ms (~ 50 fps)
- le code de rendu utilise les textures (mises à jour ou non) pour dessiner les rectangles.
- Le rendu uniquement lorsqu'une vidéo arrive ne fonctionnera pas en raison de la présence de 2 flux vidéo (asynchrones); En plus, il faut attirer plus de choses à l'écran.
- seules les commandes OpenGL de base sont utilisées (pas PBO, FBO, VBO, ...) La seule problématique chose pourrait être l'utilisation de shaders (disponible seulement à partir de Qt 4.7), mais son code est trivial.
- J'ai utilisé OpenGLProfiler et Instruments. Rien de spécial/étrange n'a été observé.
Certaines choses que je soupçonne (conclusions)
- il est clair qu'il n'est pas un problème matériel. Le même ordinateur se comporte différemment
- cela me donne la sensation que c'est un problème de filetage/verrouillage mais, pourquoi?
- le carbone est de 32 bits. L'application 10.5 était de 64. Il n'est pas possible de développer 64 bits en carbone.
- pour donner la cause possible de 32 bits, je reconstruis aussi le premier projet pour 32 bits. Cela fonctionnait en partie pareil.
- J'ai lu quelque chose au sujet de carbone ayant des problèmes (plus que d'habitude) avec la commutation de contexte.
- peut-être l'implémentation OpenGL est Multithread et le code ne l'est pas? (ou le contraire?) Cela pourrait causer beaucoup de décrochages.
- peut-être gérer le carbone des événements différemment de ceux du cacao? (je veux dire l'envoi de signal/événement, boucle principale ...)
Ok, c'est (désolé pour l'écriture si longue) mon mal de tête réel. Toute suggestion, idée .. serait très appréciée.
Thx à l'avance.
http://www.carbondev.com/site/?page=64-bit+Carbon Cela peut être utile. Apple maintient le carbone, mais n'ajoute pas de nouvelles fonctionnalités, donc je pense qu'ils ne changeront rien sous le capot. Ils n'optimiseront probablement rien, car leur objectif principal est d'aller complètement à Obj-C sur leur plate-forme –