[Images] Taille mémoire

Version imprimable

07/06/2007, 15h37
Neige_

[Images] Taille mémoire

Bonjour, je développe actuellement un petit soft java en 2D.

Graphiquement, je me sert de multiple sprite que j'affiche à l'écran, en les superposant les uns sur les autres.
Ca donne un nombre de sprite important; or le problème ne vient pas le l'affichage (vitesse correcte et aucun clipping), mais de la taille mémoire engendré.

Effectivement, j'ai comme l'impression que java "décompresse" les images en mémoire. Ce qui fait qu'un fichier gif de 50 ko devient en mémoire une bufferedImage de 1Mo.

Certes, l'Api Java spécifie qu'une bufferedImage est en réalité constitué de deux images, l'image "mémoire" et l'image "affichable". N'empêche que dans ce cas, la bufferedImage devrait prendre 100Ko... Je m'interroge.

J'ai donc par la suite essayé de passer directement par l'objet Canvas, qui permet de n'utilisé qu'une image, celle affichable. On y gagne donc 50%, ce qui fait quand même 500ko...

Même ainsi, mon programme utilise près de 100Mo de mémoire pour des images qui, sur le disque, en prennent à peine 5. (Précisons que je suis obligé de les garder en mémoire, je ne peut pas faire de l'accès disque ad vitam)

Si quelqu'un a une idée, elle sera bienvenue.

Neige
www.neonym-rpg.org
07/06/2007, 15h46
leyee

Je te conseille d'utiliser un profiler afin d'analyser finement quels sont les objets de ton programme qui pèsent tant. Je te conseille tptp sous eclipse (ne marche malheuresement pas avec java 1.5 ou 6.0) ou bien le profiler de Netbean qui est tres bien aussi.
Je suis interessé par ce que tu vas obtenir, j'ai deja observé ce genre de phenomene dans des appli où je faisais du java 2d
07/06/2007, 16h42
Sanguko

Citation:

Envoyé par Neige_

Bonjour, je développe actuellement un petit soft java en 2D.

Graphiquement, je me sert de multiple sprite que j'affiche à l'écran, en les superposant les uns sur les autres.
Ca donne un nombre de sprite important; or le problème ne vient pas le l'affichage (vitesse correcte et aucun clipping), mais de la taille mémoire engendré.

Effectivement, j'ai comme l'impression que java "décompresse" les images en mémoire. Ce qui fait qu'un fichier gif de 50 ko devient en mémoire une bufferedImage de 1Mo.

Pour connaitre la taille approximative d'une image decompressée, regarde ce post

C'est normal de décompresser une image avant de l'afficher. Ca n'est pas specifique à java, quelque soit le langage, ce sera toujours comme ca. Parce qu'il faut du temps pour decompresser une image, et le faire à la volée, c'est pas rentable.

Citation:

Envoyé par Neige_

Certes, l'Api Java spécifie qu'une bufferedImage est en réalité constitué de deux images, l'image "mémoire" et l'image "affichable". N'empêche que dans ce cas, la bufferedImage devrait prendre 100Ko... Je m'interroge.

Je ne vois pas ce que tu entends par image "mémoire" et image "affichable".

Citation:

Envoyé par Neige_

J'ai donc par la suite essayé de passer directement par l'objet Canvas, qui permet de n'utilisé qu'une image, celle affichable. On y gagne donc 50%, ce qui fait quand même 500ko...

8O je ne vois pas d'ou ca sort ... L'objet Canvas ne permet pas d'économiser une image.

Citation:

Envoyé par Neige_

Même ainsi, mon programme utilise près de 100Mo de mémoire pour des images qui, sur le disque, en prennent à peine 5. (Précisons que je suis obligé de les garder en mémoire, je ne peut pas faire de l'accès disque ad vitam)

Si quelqu'un a une idée, elle sera bienvenue.

Si tu postes un peu de temps code, je pourrai me faire une idée.
07/06/2007, 17h52
Neige_

Citation:

C'est normal de décompresser une image avant de l'afficher. Ca n'est pas specifique à java, quelque soit le langage, ce sera toujours comme ca. Parce qu'il faut du temps pour decompresser une image, et le faire à la volée, c'est pas rentable.

Je suis bien d'accord. Le soucis vient justement du fait que ce ne soit pas optimisable. Pourquoi stocker 4 octects par pixel, alors que j'utilise le gif pour justement n'en avoir qu'un ? Peut etre il existe une méthode pour forcer java a utiliser les 255 couleurs 'standart' et ainsi économiser 3/4 de mémoire ?
Mais on est bien d'accord sur le fait qu'il faut a tout prix que l'image soit décompressé.

Citation:

Je ne vois pas ce que tu entends par image "mémoire" et image "affichable".

Citation:

je ne vois pas d'ou ca sort ... L'objet Canvas ne permet pas d'économiser une image.

Prenons une image. L'image en mémoire n'est pas la même que celle à l'écran. Celle qui est a l'écran est une adaptation de celle en mémoire, dépendante de l'écran. BufferedImage retiens en mémoire les deux (voir getSource->ImageProducer, et les deux classes qui l'utilisent: FilteredImageSource, MemoryImageSource)
Donc il me semble, d'après comment c'est formulé, qu'en créant une Buffered, tu crées deux fois l'image en mémoire. Un .flush() sur une buffered efface l'image adapté, mais pas celle en mémoire. Si quelqu'un pouvait confirmer, ceci est juste une explication que je me suis faites d'après la javadoc.

Le coup du canvas, c'est que justement on peut créer des image directement adapté a l'écran. Donc en mémoire, on a que l'image affichable, et plus celle d'origine... soit 50% d'eco. Mais pareil, dixit javadoc...

Je vais donc regarder en détails comme dit leyee, et je vous dirais dès que possible ce qu'il en est.

Citation:

Si tu postes un peu de temps code, je pourrai me faire une idée.

Je n'en ai pas sous la main, mais imagine beaucoup d'instances de BufferedImage chargés en début du jeu depuis des fichiers gif, puis conservé tout du long durant le process d'affichage, et tu auras une idée du code...

Neige
www.neonym-rpg.org
07/06/2007, 18h08
sinok

Autre chose, rend tes images compatibles , utilises la méthode adéquate issue de la classe de Gfx: http://developpez.net/forums/showpos...64&postcount=3
Celà permet de bien s'assurer de la compatibilité de ton image avec la carte graphique u ce qui en tient lieu
07/06/2007, 19h21
Sanguko

Citation:

Envoyé par Neige_

Je suis bien d'accord. Le soucis vient justement du fait que ce ne soit pas optimisable. Pourquoi stocker 4 octects par pixel, alors que j'utilise le gif pour justement n'en avoir qu'un ? Peut etre il existe une méthode pour forcer java a utiliser les 255 couleurs 'standart' et ainsi économiser 3/4 de mémoire ?
Mais on est bien d'accord sur le fait qu'il faut a tout prix que l'image soit décompressé.

Quand tu executes :

Code:

BufferedImage image = ImageIO.read("image.gif");

tu obtiens une image en couleurs indexées.

Citation:

Envoyé par Neige_

Prenons une image. L'image en mémoire n'est pas la même que celle à l'écran. Celle qui est a l'écran est une adaptation de celle en mémoire, dépendante de l'écran. BufferedImage retiens en mémoire les deux (voir getSource->ImageProducer, et les deux classes qui l'utilisent: FilteredImageSource, MemoryImageSource)
Donc il me semble, d'après comment c'est formulé, qu'en créant une Buffered, tu crées deux fois l'image en mémoire. Un .flush() sur une buffered efface l'image adapté, mais pas celle en mémoire. Si quelqu'un pouvait confirmer, ceci est juste une explication que je me suis faites d'après la javadoc.

La transformation se fait parfois à la volée, ca dépend du colormodel de l'image source et de l'écran.
Mais si des données intermediaires sont créées, c'est pour un souci de performances. Sans elles, ton affichage serait trop lent.

Citation:

Envoyé par Neige_

Le coup du canvas, c'est que justement on peut créer des image directement adapté a l'écran. Donc en mémoire, on a que l'image affichable, et plus celle d'origine... soit 50% d'eco. Mais pareil, dixit javadoc...

Tu peux faire la meme chose, avec des BufferedImage. L'idee, c'est que tu utilises un BufferedImage, ayant le meme ColorModel que l'ecran (avec les methodes createCompatibleImage()). Tu dessines dans ta BufferedImage l'image decompressée, que tu oublies ensuite.