Discussion :

[tchize_]

Bonjour,

j'ai une application qui, pour des raisons de performances (IOs) a besoin de précharger en mémoire pas mal d'images. Sans préchargement, l'animation "laggue". Le stock d'images concerné, une fois chargé sous forme de bufferedimages, occupe environ 2.5G en java, et j'essaie de réduire. (en plus, il faudrait que je charge un deuxième stock de la même taille, mais c'est moins important).

Si j'étais sur une appli opengl, j'utiliserais des textures compressées (DXT1, etc). Je cherche à avoir quelque chose de similaire avec les bufferedimage, et plus précisément derrière, avec batik

Avant de me lancer dans les ajustements spécifiques à batik, je voudrais savoir si il est possible, en java, d'avoir une BufferedImage compressée, par exemple en RLE, ce qui conviendrais très bien à mon style d'image ayant de grands à plats.

Bref, j'ai environ 200M de pngs à faire tenir en BufferedImages

[dinobogan]

J'imagine que tu n'as pas besoin de toutes ces images en même temps.
As-tu pensé à un système "prédictif" afin de déterminer l'ensemble des images qui seront utilisées dans le futur immédiat ?
Exemple d'un déroulement naïf :
1. init du programme, préchargement d'un premier lot d'images, celles qui sont toujours utilisées au début,
2. dans le déroulement du programme, tu supprimes toutes les images qui ne seront plus utilisées dans l'immédiat,
3. tu ajoutes toutes les images qui seront utilisées dans un futur proche.

Le principe est de deviner les images qui seront utilisées assez longtemps à l'avance pour avoir le temps de les charger avant de les utiliser, sans le faire trop longtemps à l'avance pour ne pas remplir la RAM.
Selon le programme que tu fais, le système prédictif peut être absolu : tu es sûr et certain des images à supprimer du lot et des images à ajouter, ou alors statistique : à partir de X% de chance d'utilisation, tu charges.

[tchize_]

oui mais non

en gros c'est l'image de fond d'un programme d'animation. Donc quand on clique sur "play", je dois pouvoir soutenir raisonnablement 25 images par secondes.

Or pour le moment, lire depuis le disque vers une BufferedImage bouffe 1 seconde.

Donc il me faudrait 25 cores pour arriver à suivre la cadence


Je voudrais vraiment arriver à garder en mémoire quelque chose de complet et réactif.

PS: et après vérification, c'est bien le décodage CPU du png qui bouffe et pas les IO: j'ai caché les byte[] que chaque fichiers en mémoire pour passer des ByteArrayInputstream au décodeur sans gain.

[dinobogan]

Ton programme serait une sorte de viewer d'images qui les affiche les unes après les autres à la cadence d'une vidéo ?

[tchize_]

Non, ce programme permet de dessiner des animations vectorielles, le png sert de guide et fera partie de l'animation finale. Le soucis, c'est quand on veux faire une preview de l'animation, il faut un débit raisonnable d'image (10 à 20 par seconde). Et j'ai un problème, si je ne précache pas en mémoire les images de fond, le decodage png ne suit pas le débit requis

Donc, oui, grosso modo, une partie du programme se comporte comme un viewer faisant défiler les images les unes après les autres.