2010-11-26 17 views
2

Je suis en train de créer une application graphique dans Qt avec des fonctionnalités similaires à Google Maps (vous pouvez faire un panoramique/zoom et plus de la carte s'affiche). En ce moment, je charge dynamiquement 256 blocs de pixels des images comme ils sont requis (à partir du disque dur). Comme vous pouvez l'imaginer, cela ralentit mon programme lorsque je fais un panoramique ou un zoom. Je veux utiliser un thread séparé (MapLoader) pour charger les images comme elles sont nécessaires.Streaming QImages dans Qt 4.7

Ma classe de données a un triple pointeur vers les images (c'est-à-dire QImage * [x] [y]). Les images en dehors de la fenêtre d'affichage sont null alors que celles à l'intérieur de la fenêtre sont des pointeurs QImage.

Mon problème est, je veux que mon peintre puisse accéder à la série d'images et les dessiner (qu'elles soient chargées ou non). Tout en chargeant les images dans le tableau sans bloquer l'accès au tableau.

Comment puis-je résoudre ce problème? Est-ce que le tableau d'images doit être volatile?

Répondre

0

Il y a une belle démo sur QtLabs (avec vidéo) d'une application de test qui serait adaptée à votre situation. C'est un navigateur d'images qui charge les images dans une grille. Bien que l'auteur déclare que ce n'est pas une solution optimale, je pense qu'il devrait contenir des informations utiles pour l'utilisation de threads pour charger le contenu. Vous pouvez le voir here. Je pense qu'il y a peut-être aussi des liens intéressants dans la section des commentaires.

0

Vous devriez être en mesure d'engendrer le chargement des images sur des threads de travail, et ces fils vous signalent quand une image est prête, avec l'emplacement de l'image. (Utiliser QtConcurrent serait ma première inclination pour cela.) Si vous utilisez les connexions signal/slot, par défaut Qt s'assurera qu'un slot est exécuté dans son thread approprié. Alors faites classer vos images dans le thread de l'interface utilisateur, faites en sorte que les threads de travail émettent des signaux avec les images lorsqu'elles sont lues et que le slot de la classe image (toujours dans le contexte de thread UI) stocke correctement les images. Étant donné que l'assignation dans la carte et la lecture de la carte sont dans le même contexte de thread, vous ne devriez pas avoir besoin de marquages ​​ou de verrouillage volatiles.