J'ai fini par évaluer qu'avec ma carte graphique, il fallait en moyenne, pour la partie affichée de chaque image dont l'opacité n'est pas à 0% 3.2 ms pour traiter 1 Mpx (mégapixel = 1024 x 1024 pixels) d'image et 4 ms pour traiter 1 Mpx de sa représentation à l'écran pour la seule partie incluse dans la zone de visualisation.
Les calculs sont proportionnels à la taille de l'image et aussi à la taille de sa représentation à l'écran, dans la limite de la zone de visualisation.
Ce qui est valable pour ma carte l'est aussi pour les autres, seules les valeurs peuvent différer.
Ces calculs sont faits pour toute image ou partie d'image positionnée dans la zone de visualisation, même si à l'affichage elle est masquée par une autre image. Ils ne s'appliquent pas aux images à 0% d'opacité ni à celles hors zone de visualisation (par exemple une image dont le Pan horizontal est à 200%).
Les calculs pour une image partiellement dans la zone de visualisation sont proportionnels à la surface incluse dans la zone de visualisation., et environ 15 fois plus faibles pour la partie hors zone de visualisation, donc la plupart du temps négligeables pour cette partie.
Les calculs relatifs à l'affichage sont proportionnels à la taille affichée de l'image ou la partie d'image et dépendent donc de la résolution d'écran utilisée à la lecture.
Je n'ai pas mis en évidence d'écart notables en fonction du rapport de ré-échantillonnage (ni du zoom du reste).
Pour exemple, sur ma machine, une image de 1280 x 960 dont le Pan horizontal serait à 100% (donc la moitié en zone de visualisation) et affichée sur un écran en 1600 x 1200 aurait besoin de :
Pour les calculs sur l'image elle-même :
640 x 960 pixels = 614 400 pixels soit 0.59 Mpx
à raison de 3.2 ms/Mpx cela donne 1.875 ms pour le calcul sur l'image.
Les calculs pour sa représentation à l'écran se ferait sur une dimension de :
800 x 1200 pixels = 960 000 pixels soit 0.92 Mpx
à raison de 4ms/Mpx cela donne 2.930 ms pour la représentation écran de l'image, soit donc au total un temps total de calcul d'environ 5.5 ms et une fréquence d'image, sous réserve qu'elle soit seule, de 180 images par seconde, la fluidité étant atteinte à partir de 24 images/seconde.
Nota les valeurs indiquées sont des valeurs moyennes pouvant avoir des écarts de 15% dans certains cas. Les ré-échantillonnages pour agrandir semblent légèrement meilleurs qu'en sens inverse mais cela reste dans la fourchette des 15%.
Pour les rectangles, seules la partie représentation à l'écran est calculée, mais contrairement aux images, même pour les rectangles transparents, ce qui est quelque fois gênant.
Contrairement à ce que je pouvais imaginer, les calculs ne sont pas fait hiérarchiquement en fonction de l'arborescence, mais objet par objet quelque soit son niveau dans l'arborescence. Il y a surement une raison à ça mais je ne la connais pas.
Le double calcul (image et représentation) se fait autant de fois qu'il y a d'images avec opacité non nulle à l'écran et autant de fois le calcul de la représentation qu'il y a de rectangles dans la zone de visualisation.
La fréquence d'affichage possible et donc la fluidité dépend de la somme des calculs nécessaires pour l'affichage des objets inclus dans la zone de visualisation (fréquence x durée = 1).
Lors des transitions, c'est l'ensemble des objets des 2 vues, présents dans la zone de visualisation qui est pris en compte.
Les objets pris en compte lors des calculs à une position donnée sont ceux dont la position en question est incluse dans leur intervalle, hors de celui-ci, aucun calcul n'est effectué sur l'objet.
Un fichier de tests est disponible ici, contenant un album permettant de vérifier les constats décrits ci-dessus et un fichier exe permettant d'évaluer la puissance de calcul des cartes graphiques.