Discussion :

[eclesia]

Bonjour,

je suis confronté à des problemes de memoire. J'utilise des BufferedImage afin d'afficher mes données. Dans certain cas je dois en stocker une 60ene.
Et la taille du bufferedImage change avec la resolution.

sur mon 22" je genere des bufferedImage d'environ 1100*700 pixels. Chaque BufferedImage me coute au alentour de 4Mo de memoire.

donc 60*4 = 240Mo (je suis doué en calcul hein? )

Bref c'est lourd, ce genre d'application doit pouvoir tourner sur des machines 24", des doubles ecrans ...etc... donc la taille memoire de chaque bufferedimage va encore grossir un peu.

Seulement voila, je me suis rendu compte que chaque bufferedimage MEME vide (entendez entierement transparant) me coute 4Mo !

Existe t il un moyen d'utiliser une technique de compression?
Meme rudimentaire, je gagnerai enormement de memoire car il y a enormement de "blanc" dans chaque bufferedimage.


J'essai aussi de trouver du coté du stockage sur la vram (memoire de la carte video), si vous avez deja essayé.

Ou si vous avez d'autres solution?

[sinok]

Pour la Vram ce ne sont pas des BufferedImage mais des VolatileImage qu'il faut utiliser.

Sinon essaies de créer tes BufferedImag en tant que compatibles avec le hardware machine
cf ce post de Gfx

http://www.developpez.net/forums/sho...64&postcount=3

Accessoirement il faut comprendre que des BufferedImage ne sont absolument pas compressées, en effet pour pouvoir les manipuler elles ne doivent pas être compressés point barre.

[eclesia]

Je n'utilise la classe BufferedImage qu'au debut, (le temps de dessiner dessus) apres quoi je pourrais la stocker sous n'importe quelle forme du moment que je peux l'afficher par la suite avec un object Graphics/Graphics2D.

VolatileImage : j'y ai pensé mais celle ci peut etre perdu a tout moment, ce qui me force à la redessiner si necessaire.
Et redessiner peut prendre pres d'une seconde voir plus. Je ne peux pas me permettre de perdre en fluidité d'avantage :/
d'autant plus si je dois redessiner plusieurs images...

[Sanguko]

Pour être affichée, une image est toujours décompressée. Et prends donc de la place.

Ce que tu suggères, c'est que l'image soit décompressée, affichée, puis libérée. C'est trop couteux en temps. Personne ne fait ca.

Tu pourrais éventuellement créer les images en couleurs indexees, pour diviser taille par 4, encore faut-il que le hardware sache copier rapidement ce type d'images à l'écran.

Il faut à mon avis changer la conception. Utiliser 60 images plein ecran, ca me parait pas réaliste.

J'imagine que tes 60 images correspondent à des calques?

[eclesia]

Il faut à mon avis changer la conception. Utiliser 60 images plein ecran, ca me parait pas réaliste.
J'imagine que tes 60 images correspondent à des calques?

Si on veut oui, exemple :
http://altersig.developpez.com/snaps...rsig_root7.jpg


Si tu as des idées. comment devrais-je faire?

[Baptiste Wicht]

Tes 60 images, c'est quoi ? Une image pour ce qui est affichée et les autres sont les zones proches ? Est-ce qu'avoir 60 zones en mémoire n'est pas trop ?

Ou alors, c'est autre chose tes images ?

[eclesia]

chaque image correspond a une couche d'information. (chaque noeud dans l'arbre si vous preferez)

Pour le moment j'ai essayé trois solutions :

1) Une seule image pour tout :
- inconvenient : c'est long a dessiner, le moindre deplacement ou la moindre modification de style me force a tout redessiner
- avantage : tres faible memoire necessaire, fluide pour le rendu de composant superposé à la carte

2) Une image par couche d'information, dans un jlayeredpane :
- inconvenient : espace memoire enorme, peu fluide pour le rendu de composant superposé
- avantage : les modifications sur une couches n'entraine que de redessiner cette couche, gain en vitesse proportionnel au nombre de couches.

3) Une image par couche d'information + un merge :
(je superpose toutes les images dans une seule pour l'affichage)
- inconvenient : espace memoire enorme +1
- avantage : les modifications sur une couches n'entraine que de redessiner cette couche, gain en vitesse proportionnel au nombre de couches. fluide pour le rendu de composant superposé à la carte

Cette derniere solution est celle qui apporte le plus de fluidité dans l'application, mais a un cout memoire important : 4Mo*couche + 4Mo


Les solutions a risques :
- VolatileImage, possibilté de perte d'une image, donc redessiner... ce qui prend du temps. Et comme il y en a beaucoup pour un volume memoire important, il y aura forcement des pertes d'images.

[Sanguko]

A mon avis, tu ne devrais faire des BufferedImage que pour les "calques" qui contiennent beaucoup d'éléments.
Pour les autres, tu devrais te contenter de redessiner à chaque fois, ce qui ne devrait pas être pénalisant en termes de perf.

[eclesia]

A mon avis, tu ne devrais faire des BufferedImage que pour les "calques" qui contiennent beaucoup d'éléments.
Pour les autres, tu devrais te contenter de redessiner à chaque fois, ce qui ne devrait pas être pénalisant en termes de perf.

Je dois preserver l'ordre d'affiche, les couches l'unes au dessus de l'autres.
Si je regroupe les legeres, mon ordre est faussé.
Et si je me retrouve avec des couches volumineuses entre chaques couche legere je n'aurais aucune économie.

De plus comment faire le tri de ce qui est considéré comme volumineux ou non? je ne sais pas a l'avance le temp que prendra une couche a etre dessiné. (c'est un autre objet qui n'est pas de moi qui se charge de faire le dessin)

[Sanguko]

Je dois preserver l'ordre d'affiche, les couches l'unes au dessus de l'autres.
Si je regroupe les legeres, mon ordre est faussé.
Et si je me retrouve avec des couches volumineuses entre chaques couche legere je n'aurais aucune économie.

De plus comment faire le tri de ce qui est considéré comme volumineux ou non? je ne sais pas a l'avance le temp que prendra une couche a etre dessiné. (c'est un autre objet qui n'est pas de moi qui se charge de faire le dessin)

Je pensais plutot à une classe de type Layer, qui gère l'affichage d'une couche. Cette classe contiendrait l'ensemble des éléments à dessiner sur cette couche.
En fonction du nombre d'élements, soit tu fais le dessin directement, soit tu le fais dans un BufferedImage, qui tu réutilises pour les affichages suivants.

[eclesia]

En fonction du nombre d'élements

ce n'est pas aussi evident, une couche de données s'étant bien au dela de la zone visible sur la carte. il y a donc des elements par forcement representé sur la zone que l'on regarde. Il y a aussi le style graphique appliqué a la couche de données.

une couche de points par exemple peut etre symboliser par des images png, a ce moment la, meme s'il n'y a que peu de point, le temps de dessin sera long.

Faire un algorythme qui calcul qu'elles sont les elements dans la zone interessé puis qui examine le style pour juger si oui ou non il doit faire un bufferedimage, ca va etre long. :/

[sinok]

Tite question en passant: quand tu as plusieur fois la même image à afficher, tu iunstancie plusieurs fois la même image ou une seule fois.
Une autre possibiilité serait de regrouper toutes les petites images dans une seule plaque et de récupérer la partie de l'image correspondant à ce que tu veux afficher.

[eclesia]

Tite question en passant: quand tu as plusieur fois la même image à afficher, tu iunstancie plusieurs fois la même image ou une seule fois.

Je ne le fais qu'une seule fois heureusement , et je mets a jour mon image uniquement quand necessaire, j'y ai veillé.

Une autre possibiilité serait de regrouper toutes les petites images dans une seule plaque et de récupérer la partie de l'image correspondant à ce que tu veux afficher.

je perdrai l'ordre d'affichage :/

[Sanguko]

Faire un algorythme qui calcul qu'elles sont les elements dans la zone interessé puis qui examine le style pour juger si oui ou non il doit faire un bufferedimage, ca va etre long. :/

Et pourquoi mesurer le temps de tracé? En fonction du temps pour quelques elements, tu pourrais extrapoler et decider de tracer dans un buffer ou directement à l'écran.

[sinok]

En fait non ce que je propose c'est au lieu d'instancier 100 image différentes (une par imag à afficher) tu les regroupes dans une seule image (une plaque d'icônes par exemple) puis tu viens chercher l'image dont tu as besoin à grand coup de getSubimage pour la dessiner sur ton conteneur de destination, comme celà au lieu de 100 images instanciées, tu en as une seule.

[kerinel]

Je dois preserver l'ordre d'affiche, les couches l'unes au dessus de l'autres.
Si je regroupe les legeres, mon ordre est faussé.
Et si je me retrouve avec des couches volumineuses entre chaques couche legere je n'aurais aucune économie.

De plus comment faire le tri de ce qui est considéré comme volumineux ou non? je ne sais pas a l'avance le temp que prendra une couche a etre dessiné. (c'est un autre objet qui n'est pas de moi qui se charge de faire le dessin)

Bonjour,
une question de néophyte:
Pourquoi se préoccuper de savoir ce qui est léger et ce qui et volumineux ?
Si le problème est un équilibre entre rapidité/place mémoire, pourquoi ne pas regrouper arbitrairement 4 ou 5 couches consécutives sans se soucier si elles sont légères ou pas. Ainsi lors d'une modification, seulement 4 ou 5 couches sont redessinées (donc plus rapide que la solution une seule image pour tout mais un peu plus lent que 60 images, surtout si manque de bol, on a 5 couches volumineuses...) par contre la place en mémoire est divisée par 4 ou 5 par rapport à la solution 2.
Bon c'est peut être trivial comme suggestion...
Sinon si tu ne sais pas le temps nécessaire pour redessiner, peut être peux tu connaitre la zone intéressé et ne redessiner que cette partie avec un masque mais bon tu dois déjà avoir essayé .

Bon code,
kerinel

[eclesia]

Sinon si tu ne sais pas le temps nécessaire pour redessiner, peut être peux tu connaitre la zone intéressé et ne redessiner que cette partie avec un masque mais bon tu dois déjà avoir essayé .

heureusement c'est deja fait ^^.

Si le problème est un équilibre entre rapidité/place mémoire, pourquoi ne pas regrouper arbitrairement 4 ou 5 couches consécutives sans se soucier si elles sont légères ou pas. Ainsi lors d'une modification, seulement 4 ou 5 couches sont redessinées (donc plus rapide que la solution une seule image pour tout mais un peu plus lent que 60 images, surtout si manque de bol, on a 5 couches volumineuses...) par contre la place en mémoire est divisée par 4 ou 5 par rapport à la solution 2.

c'est bien un probleme rapidité/memoire mais la seule technique qui atteind le minimum raisonnable est celle du une image par couche.