Tests de fluidité

[JPD]

admin1 :
Ce fil est constitué de post provenant de Fantaisies florales, mais concernant des tests, ces posts ont été mis dans une rubrique plus adéquate
Avant de me lancer dans la réalisation d'un fichier test plus conséquent, j'ai réalisé un test, comportant 2 montages qui donnent le même résultat sur une machine moyenne, mais dont l'un devrait marcher sur la machine de Patrick et l'autre non (du moins c'est ce que j'espère). L'un des 2 a été conçu pour être "limite" sur la machine de Bernard, mais devrait passer.
Le lien vers ce test était ici
Il est composé de 2 fichiers A et B.
Je vous serait très reconnaissant de me donner les résultats (fonctionne ou pas et fluidité) en m'indiquant si possible la taille de la mémoire graphique.
Merci d'avance

[yugtayom]

PSS...PSS... le lien ne fonctionne pas

GUY

[JPD]

Merci Guy, c'est réparé, encore une étourderie (et aussi la manie du copier/coller)

[yugtayom]

256 ATI radeon x 2

çà roule d'enfer,
j'ai mis 1minutes 30 ... environ à me rendre compte que çà tournait sans fin et même j'avais l'impression que çà se déplaçait de G à D


GUY

[eric]

Meme constat que Patrick
Radeon x600 128 Mo

[potesta]

Bonjour Jean-Pierre,

Les 2 versions très fluides.

Définition d'écran 1280 X 1024

Pentium IV, 3 Ghz
SDRAM 512 Mb
NVIDIA GEFORCE FX 5600 128 Mb.

[Administrateurs]

Merci à tous d'avoir pris un peu de temps pour ce test.
Ne m'attendant pas à ce que ça fonctionne chez Patrick, les résultats ne me permettent pas de tirer, sans tests complémentaires, des conclusions viables.
Les deux fichiers étaient réalisés comme suis:
L'un (A) est composé d'une seule vue chargeant donc en mémoire les 128 objets constituant l'animation, ce qui fait qu'il y a 28.60 Mo en mémoire graphique à un même instant. Toutes les cartes acceptant ces 28.6 Mo auront une bonne fluidité, celles ne les acceptant pas donneront une image très saccadée.
Le second est composé de 8 vues comportant chacune 16 objets, la mémoire nécessaire n'étant plus alors que de 7.15 Mo (3.57 Mo pour la vue en cours et autant pour la vue suivante). Cette méthode permet de fonctionner avec beaucoup moins de mémoire de carte graphique, mais elle nécessite un rechargement permanent depuis la mémoire vive du PC vers la mémoire de la carte graphique, ce qui explique qu'elle soit moins fluide.
En 1600x1200 sur ma machine, le fichier le moins fluide (B) plante au bout de 30 secondes alors que le second (A) fonctionne (pas parfaitement) jusqu'au bout.
Dans les résolutions inférieures, le A est plus fluide que le B.
Je continue donc avec d'autres tests pour essayer de trouver quels sont les paramètres qui jouent sur la fluidité (en particulier la définition d'écran).

[yvan]

pas de différence chez moi.
écran : 1280*1024.
mémoire: 2*512 mo.
carte vidéo : nvidia ge force fx 5500 avec 256 mo.
cordialement,yvan.

[Invité]

AMD ATHLON XP PROCESSOR
3000+
1,3 GIGAHZ
512 MO RAM

NVIDIA GFORCE 4440 Go 64MO

Voilà pour mon portable
La A plus fluide que la B mais les deux passent bien:)
Bon courage pour vos tests
Jolie boule de fleurs en tout cas:)

[Administrateurs]

Tu as raison Jean-Pierre, j'ai fait une inversion des lettres, j'ai corrigé. Merci de m'avoir alerté.

[JPD]

Si je pousse la résolution de mon écran à 1280x960 de temps en temps j'ai un décrochage, il ne passe plus

Je ne pense pas que ce soit spécifiquement ta carte qui soit en cause, ça fait à peu près la même chose avec d'autres cartes ayant la même quantité de mémoire.
Pour moi aussi, si je pousse la définition, Versailles pose un problème avec ma Radéon 64 Mo.
Il est possible qu'il faille de la mémoire disponible pour stocker l'image affichée, et ce besoin de mémoire augmente avec la définition d'écran, de plus les calculs pour la construction de l'image doivent augmenter sérieusement. (il y a près de 2.5 fois plus de pixels à calculer en 1600 x 1200 qu'en 1024 x 768).
Je ne connais pas la raison exacte, mais il faut chercher dans ces directions.

[JPD]

Constatations faites à propos de la gestion de la mémoire de la carte graphique :

Cela a été fait sur ma machine, donc ce n'est pas forcément reproductible systématiquement, néanmoins il est probable que ce ne soit pas éloigné de ce qui se produit sur d'autres systèmes.
J'ai repris l'animation déjà utilisée, j'ai fait des copies de la vue initiale composée de 128 objets de 234 256 octets chacuns soit un total de 29 984 768 (28.6Mo).

A la vue 2, j'ai adjoint un fichier de 1024 x 768 soit 2 359 296 octets (2.25 Mo), à la vue 3, 2 fichiers 1024 x 768 et ainsi de suite. Je me suis arrangé pour que sur une vue il y ait exactement 64Mo moins quelques octets.

Lorsque je lance ce test en 1024 x 768, l'animation fonctionne jusqu'à 64 Mo, il ne semble donc pas y avoir besoin de mémoire pour stocker l'image affichée, toute la mémoire est utilisée pour stocker les fichiers à traiter.

Le même test à une définition d'écran de 1152 x 768 fonctionne à 62.35 Mo, mais s'immobilise (et plante la machine) à 64 Mo, il faut donc de la mémoire (au plus 1.65 Mo) pour stocker des traitements intermédiares.

Le même test à une définition d'écran de 1280 x 1024 fonctionne à 60.10 Mo, mais s'immobilise (et plante la machine) à 62.35 Mo, il faut donc de la mémoire (entre 1.65 Mo et 3.9 Mo) pour stocker des traitements intermédiares.

Le même test à une définition d'écran de 1600 x 1200 fonctionne à 51.10 Mo, mais s'immobilise (et plante la machine) à 53.35 Mo, il faut donc de la mémoire (entre 10.65 Mo et 12.9 Mo) pour stocker des traitements intermédiares.

Ces valeurs de mémoire nécessaires probablement pour des traitements intermédiaires ne sont pas proportionnelles avec la définition d'écran il est difficile d'en extrapoler une loi, mais cette fontion n'est pas linéaire, c'est une certitude.

D'autre part, toujours sur ma machine, tant qu'on reste en dessous des 32 premiers Mo, c'est parfaitement fluide, au dela c'est nettement saccadé, comme si la mémoire au dela de 32 Mo était beaucoup moins rapide, mais ce phénomène est probablement lié au modèle de carte utilisé (Radeon 7500 - 64 Mo).

Ce qu'on peut légitimement en déduire, c'est qu'une vue ne doit pas nécessiter plus de mémoire que la carte en a, ce pour une définition de 1024 x 768, et doit laisser une réserve tenant compte de la définition d'écran à utiliser.

Ces tests ne valent que pour une vue, puisque les fichiers utilisés étaient les mêmes d'une vue sur l'autre.

Je vais faire des tests complémentaires car il faut aussi prendre en compte que les fichiers de la vue suivantes doivent être également en mémoire (graphique) pour avoir une transition sans à-coup.

Ci-dessous la quantité de mémoire utilisée par "Fantaisies florales" en partant du principe qu'une même image n'est stockée qu'une fois, même si elle est utilisée plusieurs fois, et en prenant 3 hypothèses (la première est fausse) :
- 1 vue complète en mémoire
- 2 vues en mémoire
- 3 vues en mémoire




Comme on peut le voir, il n'y a jamais plus de 20 Mo en mémoire graphique (sur 3 vues), ce qui expliquerait que le montage soit fluide, même en 1600 x 1200, la V2 nécessitait 10 Mo de plus, elle était "limite" pour des cartes 32 Mo (ou la mienne qui rame au dela de 32 Mo)

Constat complémentaire :
Aussi surprenant que cela paraisse, le même test passé en 1024 x 768 qui accepte jusqu'à 64 Mo de fichiers lorsque les images sont en mode anti-aliasing ne fonctionne que jusqu'à 58.51 MO sans l'option anti-aliasing, à 60.1 Mo il plante, l'essai ayant été fait 4 fois avec toujours le même résultat.
Je vais poser la question du pourquoi, mais ne suis pas sûr d'avoir une réponse.
En définition 1600 x 1200, pas de différence.

[Marcel_Auriol]

Voila j'ai moi aussi fait tourner sur ma bécane :
Pentium IV cadencé à 1,8 G°, 1 G° de Ram,
carte graphique NVidia Géforce 6600 256 M° de Ram,
Ecran 19 pouces 1280x1024,

j'ai fais tourner chaque test plus de 3 mn chacun, je dois dire que je n'ai vu aucune différence entre les 2 tests, cela semble fluide par moment mais pas forcément tout le temps.
Je pense pour que tout soit le plus fluide possible est qu'il ne faut qu'aucun programme résidant ne doit tourner en fond et l'idéal pour ce rendre compte de davantage de fluidité est de stopper l'antivirus, afin que le test puisse se dérouler dans de meilleures conditions.

C'est en tout cas mon point de vue.

De toute façon JP, toutes mes félicitations pour l'énorme travail que tu fourni et que tu vas à n'en pas douter fournir encore.

Amitiés mec et à bientôt

[JPD]

Et pourtant dans certain cas il n'y a pas de différence entre 2 vues et 3 vues

C'est un peu normal dans ce montage qui est construit un peu comme un méccano et ou nombre d'éléments sont réutilisés d'une vue sur l'autre, par exemple l'un des cubes du début est en fait présent dans 7 vues.

Pour la dernière vue, comme il n'y a plus rien à charger, il est normal que les 3 valeurs soient identiques.

Je ne crois qu'il faille trop se torturer les méninges, quand on aura un peu d'expérience, on fera comme pour la V4 : éviter les causes de plantage, en effet la V4 n'est stable que parce qu'on respecte un minimum de règles, faire un montage qui plante avec la V4, rien n'est plus facile (et ce serai la même chose avec d'autres logiciels)

[JPD]

Réponse d'Igor aux question posées :

Vous avez raison - il est important que les images soient toutes dans la mémoire de la carte graphique. Autrement elles se déplacent entre la mémoire vive du PC et la mémoire de la carte graphique en permanence.
Aux autres questions posées :
Oui, une même image utilisée plusieurs fois n'est qu'une seule fois gans la mémoire de la carte graphique.

De plus, elles sont affichées plus rapidement que deux images différentes. Il semble que les cartes graphiques ont quelques optimisations pour cela, parce que souvent dans des jeux
de la texture (image) est souvent utilisée plusieurs fois (herbe ou route par exemple).
Et l'optimisation complémentaire dans PTE - si vous avez Image1.jpg dans 2 vues consécutives, PTE le détectera et ne rechargera pas cette image de nouveau (le chargement des images prend quelque temps, vous savez).
PTE5 garde toujours 3 vues en mémoire (celle en cours et les 2 suivantes). Cela est nécessaire si certaines vues sont longues à charger. Nous avons testé plusieurs variantes et c'est la solution optimale pour l'utilisation des effets Pan/Zoom sur de grandes images.
Utilisation générale de la mémoire graphique :
3 buffers d'écran x largeur d'écran x hauteur d'écran x 4 octets
+ les images de 3 vues (largeur d'image x hauteur d'image x 4 octets)

En principe, lorsqu'il n'y a plus assez de mémoire dans la carte graphique, Windows (ou Direct X) se sert de la mémoire vive en complément de celle de la carte graphique, mais cette mémoire est très lente pour cette utilisation, d'ou saccades.

Par ailleurs, il semble que dans certains cas, par exemple le test avec la sphère, cette fonction ne soit pas possible (lors de test pour Igor, j'ai pu afficher des vues avec 89 Mo d'image alors qu'avec le test "sphère", ça plante à 64 Mo, valeur de la mémoire graphique).

J'ai demandé une précision à Igor car 4 octets/pixel pour les images sans transparence ne me semble pas logique ni correspondre aux tests effectués.

Pour l'essentel, cela confirme les tests, mais quelques contradictions restent à éclaicir.

[Invité]

Euhh en langage de blonde cela donnerait ????

Patrick tu n'es pas le seul a ne rien comprendre:o))))
Je suis certaine que JP va nous faire une tite collection d'impressions écran pour nous traduire son chinois ptéiste( rires)
Bon courage à ceux qui employent cette version incompréhensible pour moi:)