Discussion :

[ChPr]

Bonjour à toutes et à tous,

J'ai un GS2 sur lequel j'essaie une application de cartographie.

Pour définir le bitmap (4000 x 4000), à un moment j'écris :

Code :

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

bitmap = Bitmap.createBitmap(4000, 4000, Bitmap.Config.ARGB_8888);

Je remplis ensuite mon bitmap à l'aide d'un canevas : tout se passe bien.

Maintenant, je veux changer d'image. Je rappelle la même séquence avec une autre image : ça plante !!

maintenant, si je remplace ma première instruction par :

Code :

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

1
2
bitmap = Bitmap.createBitmap(1, 1, Bitmap.Config.ARGB_8888);
bitmap = Bitmap.createBitmap(4000, 4000, Bitmap.Config.ARGB_8888);

ça ne plante plus. Est-ce un problème de mémoire ? et si oui, comment interpréter cela ? J'ai l'impression que la réaffectation du bitmap cherche à se faire avant d'avoir supprimé l'ancien.

Par ailleurs, je n'ai pas l'impression que ce soit la création du bitmap qui consomme de la mémoire, mais son remplissage par la canevas.

Qu'en est-il exactement, où trouver de l'information à ce sujet ?

Merci de votre aide.

Pierre

[nicroman]

A mon avis si... ca plante a cause du 4000x4000

Tu as une bitmap de 4000x4000 (61Mo quand même !)
Elle est référencée par "bitmap"...

Que se passe-t-il quand tu repasses sur la ligne ?
bitmap pointe toujours sur l'ancienne....
il essaye de créer une deuxieme bitmap de 4000x4000 il n'y a pas de mémoire, le GC est appelé
Le GC ne trouve rien à "virer" (l'ancienne est toujours referencée) => OOM


Quand tu commences par assigner une bitmap 1x1
bitmap va désormais pointer sur une bitmap de 1x1
il essaye de créer une deuxieme bitmap de 4000x4000 il n'y a pas de mémoire, le GC est appelé
l'ancienne de 4000x4000 n'est plus référencée => elle est "collectée"... et ca "passe".


Maintenant ce code est simplement horrible... il vaut mieux mettre à jour la bitmap plutôt que la "réallouer"...
Ca tombe bien ils en parlaient sur GoogleDev il y a pas 3j...
https://www.youtube.com/watch?featur...&v=12cB7gnL6po

D'autre part allouer une bitmap en mémoire de 4000x4000 est un non-sens... quel est le but ?

[ChPr]

Merci nicroman pour ces informations.

A mon avis si... ca plante a cause du 4000x4000

Tu as une bitmap de 4000x4000 (61Mo quand même !) ...

J'ai cru comprendre que la mémoire vive disponible du GS2 était de l'ordre de 800 Mo.

... Elle est référencée par "bitmap"...

C'est un bitmap ARGB8888. Ça passe avec un RGB565.

... ton explication du GC ...

C'est effectivement ce que j'ai cru comprendre.

...Maintenant ce code est simplement horrible... il vaut mieux mettre à jour la bitmap plutôt que la "réallouer"...

C'est bien ce que je voudrais faire.

Ca tombe bien ils en parlaient sur GoogleDev il y a pas 3j...
https://www.youtube.com/watch?featur...&v=12cB7gnL6po ..

Merci pour ce lien. Déjà que je fais des contre-sens à la lecture de l'anglais. Cela me désole, mais je ne comprends absolument pas l'anglais parlé.

... D'autre part allouer une bitmap en mémoire de 4000x4000 est un non-sens... quel est le but ?

J'ai des dalles de cartographie qui font cette dimension. Je les gère par quart aux changements de dalles, mais le bitmap complet de présentation fait 4000 x 4000. Je pourrais en utiliser moins, mais cela compliquerait énormément l'algorithme de recomposition de dalles.

Je préfère, dans un premier temps, comprendre les plantages liés aux bitmap et les résoudre. Après, je reverrai certainement mes algorithmes.

Maintenant, je vais chercher comment fait pour le mettre à jour plutôt que de le réallouer.

Merci de votre aide.

Pierre

[ChPr]

Pour continuer, voici ce que je fais (Note : toutes les variabls ont été préalablement correctement déclarées):

Code :

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

1
2
3
4
5
6
options = new BitmapFactory.Options();
options.inMutable = true;
Strm = new FileInputStream(Fch1); // Fch1 = fichier image de 4000 x 4000
BRD = BitmapRegionDecoder.newInstance(Strm, true);
Rect Rct = new Rect(0, 0, 4000, 4000);     	
bitmap = BRD.decodeRegion(Rct, options); //Création du bitmap

Jusque là, ça marche. Maintenant, je voudrais modifier mon bitmap. L'idée est de créer un canevas pour utiliser la fonction drawBitmap. Mais le simple fait d'écrire à la suite du code précédent :

Code :

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

Canvas Cnv = new Canvas(bitmap);

Ca plante : je suis bloqué.

Merci de votre aide.

Pierre

[nicroman]

J'ai cru comprendre que la mémoire vive disponible du GS2 était de l'ordre de 800 Mo.

Tu as du mal comprendre... la mémoire totale native est de 800Mo, mais la mémoire d'une application "java" est limitée à 64Mo sur un Galaxy dernière génération... sur certaines devices c'est même 20Mo....

Utilise

Code :

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

1
2
 
Runtime.getRuntime().maxMemory()

pour savoir la mémoire disponible.

Bon, l'anglais pour la programmation c'est tout juste indispensable...
En gros, allouer une bitmap de la taille de l'écran est de toute manière suffisant dans 99,999% des cas. Eventuellement avec 10% de plus que l'écran histoire de "cacher" les translations éventuelles (c'est plus "fluide"), mais pas besoin de plus.

J'ai des dalles de cartographie qui font cette dimension. Je les gère par quart aux changements de dalles, mais le bitmap complet de présentation fait 4000 x 4000. Je pourrais en utiliser moins, mais cela compliquerait énormément l'algorithme de recomposition de dalles.

Je ne vois pas en quoi c'est compliqué d'autant que tu as déjà l'algo apparemment pour le changements de dalles...
Il faut juste conserver la matrice de transformation (résolution de l'écran) dans la résolution des dalles... et trouver les bons fichiers (et les "parties à lire")... a partir des coordonnées... puis d'appliquer la transformation inverse pour savoir ou l'écrire dans la bitmap de l'écran.

Juste au passage:
4000x4000 en A8R8G8B8 = 4000x4000x4 octets = 61Mo
4000x4000 en R5G6B5= 4000x4000x2 octets = 31Mo
Donc tu peux stocker 2 bitmaps R5G6B5 dans 1 seule A8R8G8B8... ce qui revient à ce que je disais... le GC ne peut rien faire en A8R8G8B8 avec cet algo.

[Hizin]

Selon les spéc' de Google, Android est garantie d'avoir 16 Mo de mémoire pour les applications. Il n'y a aucune autre info, donc pas de max, ni de minimum par version. Attention donc
La mémoire max dispo pour les applications dépendent du constructeur, de la version et de la plate-forme.