Nombreux dessins de bitmaps: et les performances alors ?Résolu

Question

Salut à tous,

J'ai une question de graphisme et de performances (ne vous laissez pas abattre par la quantité de détails de la question - au moins, moi j'en donne ^^)
Voila le topo:
- J'ai crée un composant qui permet d'afficher des images rectangulaires, tournées suivant un certain angle et qu'on peut déplacer avec la souris (j'utilise GDI+ mais ce n'est pas ici le problème).

- Lorsqu'on sélectionne une image (en cliquant dessus), celle-ci passe automatiquement au dessus des autres qui la recouvraient. De même lors d'une sélection multiple (on les sélectionne l'une après l'autre ou toutes grâce au lasso)

- Ce composant affiche de petites images (100 à 150 pixels de largeur) mais en grand nombre (50 à + de 200), d'où le chevauchement.

Voila mon problème:
Quand je déplace, tourne (rotationne ^^) une ou plusieurs images, il faut que le composant se redessine. Sauf que, avec 100 images ça prend un temps fou (et le processeur est à 100%).
Je me suis donc décidé à ne dessiner que le nécessaire. Pour cela, j'utilise une liste de rectangles à redessiner (je ne redessine que les images qui sont dans ces rectangles) et toute ma question est là.
En effet, comme les images se chevauchent, il y a un ordre d'empilement. Si je redessine une image, je dois donc redessiner avant toutes celles qui lui sont en dessous puis celles qui sont au dessus. Sauf que, avec ce système, comme beaucoup d'images se touchent, au final, il me faut tout redessiner !
Or, c'était pas le but recherché !

D'où ma question: comment gérer mes images pour ne pas avoir à tout redessiner à chaque fois ?
J'ai pensé à utiliser différents buffers (en découpant mon bitmap final en plusieurs parties indépendantes [4 colonnes * 3 lignes] et en les dessinant toutes dessus après) et cette technique fonctionne globalement assez bien.
Mais lorsque de nombreuses images sont superposées, j'ai de nouveau le même ralentissement (normal). 
Dans ce cas, comment faire pour ne redessiner que ce qui est strictement nécessaire ?
C'est vraiment casse-tête comme problème...

Mais avec toutes vos lumières, je pourrais bien faire quelque chose, non ?
Allez, à vos neurones !

f0xi · Accepted Answer

y'a peu etre deux solutions :

plan 2D/3D DirectX / OpenGL.

même photoshop rame quand t'as 200 calques.

désolé de ne pas pouvoir en dire plus.

<hr size="2" width="100%" />
http://deefaze.gnomz.com

florenth · Answer

Mouais, j'y avais pensé mais :
- est ce que OpenGL ne rame pas aussi avec 200 bitmaps ? (logiquement, moins que le CPU)
- mais surtout, comment transformer mon code pour utiliser OpenGL ??? lol 
Mon unité fait déjà 800 lignes, certes ce n'est pas tout du dessin (très peu en fait) mais ça fait relativement beaucoup de choses à modifier. De plus, je suis pas très doué en OpenGL surtout lorsqu'il s'agit de textures.
Y'a t-il un moyen "simple" d'accéder aux fonctions "basiques" d'OpenGL (càd dessin 2d, dégradés et textures, rien de plus) sans avoir à tout faire à la main ?

Merci de ta réponse, mais c'est vrai que je m'y attendais un petit peu...

PS: La seule différence avec photoshop, c'est que mes images se superposent (pas de transparence) et qu'elles font 200x150px et non pas 2048x1536 comme certaines photos...

Cirec · Answer

Salut,

Rotation avec GDI+ ... Beuark
j'obtiens de meilleurs résultats avec PlgBlt

J'arrive même à obtenir la fameuse illusion d'optique quand, à partir d'une certaine vitesse de rotation, on a l'impression que la rotation stop et repart en sens inverse ...

et en fonction de la méthode de rotation utilisée dans GDI+ (Matrice ou Tableau de 3 points) le passage à PlgBlt est très facile à réaliser
 
@+
Cirec

<hr siz="" />

florenth · Answer

Ohhh là !
Attention ! Maintenant que je me suis mis à GDI+, pas question de me faire revenir en arrière lol !

Nan, sérieusement, la rotation n'est pas le problème: si je l'enlève, ça rame toujours autant (la différence est assez faible je t'assure). Le problème vient donc d'ailleurs.

Ce qu'il faudrait, c'est implémenter une espèce de passerelle entre la VCL et OpenGL pour qu'on puisse utiliser toute sa puissance (et le GPU) au lieu de GDI comme c'est le cas par défaut.
Forman avait déjà commencé un travail là dessus, je vais m'y pencher dessus, mais c'est assez délicat...

"J'arrive même à obtenir la fameuse illusion d'optique quand, à partir d'une certaine vitesse de rotation, on a l'impression que la rotation stop et repart en sens inverse ..."
=> ça doit vraiment carburer ton animation ! Mais chez moi, je n'ai pas besoin de faire plus d'un tour toutes les minute donc...

Cirec · Answer

"ça doit vraiment carburer ton animation !"

une rotation sur 3 axes sur un cube (6 faces (images) différentes) à fond consomme moins de 30%  de charge CPU  
et je n'ai pas un cheval de course 
AMD Athlon XP 1800+
1.53 GHz, 512 Mo de RAM

GDI+ n'est même pas capable de m'afficher toutes les images l'animation est saccadée et le CPU est 100% 

 
@+
Cirec

<hr siz="" />

florenth · Answer

Mouais, mais comme tu le dis, tu n'as "que" 6 images, pas 150 !

Chez moi, avec mon P4 2.8Ghz et 512Mo de RAM, j'ai du mal à partir de 30 images.
D'ailleurs, au sujet du Hyper-Threading: si je l'active, le CPU ne monte pas à plus de 50% car GDI (+ ou pas +) ne gère pas le multi-processeur.

T'imagine: tu aurais un Quad-Core, ça n'irait même pas plus vite !!!

PS: info secrète: je crois que j'ai trouvé un moyen d'exploiter la puissance du GPU hors processus graphique pour des calculs répétifis (un peu comme MMX ou SSE) ça peut être drôlement utile... à surveiller.

florenth · Answer

Suivant le conseil de f0xi, je suis passé en OpenGL et en effet, ça tracasse beaucoup moins le CPU (on passe de 50% à 2% !!) et en plus, le déplacement est fluide.

Reste que le code est moins simple à relire du coup, OpenGL n'étant pas à un très haut niveau d'abstraction.

Nombreux dessins de bitmaps: et les performances alors ?

7 réponses

Votre réponse

Discussions similaires