Discussion :

[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.

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

[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

[Sanguko]

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.

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".

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...

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

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.

[Neige_]

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é.

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

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.

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

[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

[Sanguko]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

tu obtiens une image en couleurs indexées.

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.

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.