Discussion :

[professeur shadoko]

Bonjour

j'ai un programme awt qui déplace des gifs animés dans un Canvas.
à ma grand surprise l'animation est excellente si je branche mon Mac portable sur un grand écran auxiliaire : le déplacement est fluide et le gif s'anime sans conflit avec les déplacements....
et elle est mauvaise (ralentie , avec des sauts , des mouvements incomplets, ) si on utilise l'écran de ce même portable.

explication? pourquoi l'écran importe sur la qualité?
merci
zut: je me rends compte que mon message est mal placé: il aurait du être dans le sous-forum graphique ... comment le déplacer?

[tchize_]

synchronization verticale?

[professeur shadoko]

bon je suis arrivé à avoir une animation fluide dans tous les cas .... avec une différence étonnante:
j'ai un bonhomme qui se déplace ne marchant et il marche deux fois plus lentement sur le petit écran que sur le grand écran ...
Il y a toujours quelque chose qui m'échappe ... mais je vais essayer d'expliquer le pourquoi du comment.

Pour une raison que je ne vais pas expliquer ici le programme est constitué d'objets graphiques gérés sur un Canvas.
Chaque objet graphique contient une donnée à afficher (image, chaîne, Shape awt) plus un ensemble de données d'affichage qui lui sont propres.
Parmi ces données d'affichage il y a des AffineTransform qui dirigent le dessin de la donnée à afficher.
bon
maintenant les gifs animés ont une sale habitude: pour les dessiner on a besoin d'un ImageObserver et ils déclenchent à chaque changement d'image élémentaire
une repeinture du composant global.
Du coup on a deux threads qui se disputent le dessin: celui qui change les emplacements de dessin et celui du gif
du coup boxon total dans les opérations de dessin!

donc il m'a fallu:
- créer un ImageObserver spécial qui ne relance pas les repeintures globales du composant (mais qui repeint à sa manière l'image transformée)
- mettre des synchronized au bon endroit pour avoir des opérations de peinture cohérentes

tout ça est, bien sûr, particulièrement inefficient , mais ça marche. Je soupçonne qu'il doit y avoir des moyens moins exotiques de faire les choses ...mais pour l'instant je vais boire mon thé

à bientôt

[professeur shadoko]

je cherche quand même à comprendre pourquoi mon animation marche 4 ou 5 fois plus lentement sur l'écran du portable que sur un écran déporté.
Si je mets mon écran en recopie video alors ça se met à gazer sur les deux écrans (y compris sur celui du portable)
Je suis d'une ignorance crasse en ce qui concerne les GPU ... quelqu'un peut m'expliquer pourquoi l'écran influe de manière aussi spectaculaire sur les performances?
(un facteur de ralentissement est la présence de blocs synchronized pour s'assurer de la cohérence des dessins, par ailleurs je change les stratégies de bufferisation et ça n'a aucune influence ...)
bref ma culture est trop faible pour essayer de démonter le problème.
des suggestions?

merci
PS: je suis sur MAC

[tchize_]

la question est peut être bête, mais quand ça rame, l'écran déporté est branché? Il fait quoi? Avec le GPu de portable tu as parfois un double GPU: un lent pour la bureautique et un rapide pour le graphisme, et la partie graphisme ne s'activant que quand des systèmes lancent la 3D ou que l'écran externe est requis. Tu pourrais regarder si tu n'a pas une option pour désactiver ça. Souvent la base perf c'est un GPU intel et les perfs rapide un GPU amd / nvidia

[professeur shadoko]

la question est peut être bête, mais quand ça rame, l'écran déporté est branché? Il fait quoi?

appli sur écran portable mais sans écran déporté: lent
appli sur écran portable mais écran déporté branché et affichant d'autres applis: lent
appli sur écran portable avec recopie d'écran déporté: rapide
appli sur écran déporté alors que le portable affiche autre chose: rapide

par aileurs sur MAC pas trouvé moyen de faire joujou avec les GPUs ... mais je cherche
en fait je m'inquiète surtout de ce qui va se passer le jour où des codes de cette bibliothèque tourneront sur un PC (Win**, ou Linux**)