Plantage avec des bitmaps

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:

---

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:

---

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

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 ?

Merci nicroman pour ces informations.

Citation:

---

Envoyé par nicroman

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.

Citation:

---

Envoyé par nicroman

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

---

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

Citation:

---

Envoyé par nicroman

... ton explication du GC ...

---

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

Citation:

---

Envoyé par nicroman

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

Citation:

---

Envoyé par nicroman

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

Citation:

---

Envoyé par nicroman

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

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

Code:

---

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:

---

Canvas Cnv = new Canvas(bitmap);

---

Ca plante : je suis bloqué.

Merci de votre aide.

Pierre

Citation:

---

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:

---

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.

Citation:

---

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.

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.

Il est possible de jouer avec android:largeHeap="true"
Mais ca ne va pas casser 4 pattes à un canard de toute manière...
Si le but est d'utiliser les 800Mo (ce qui n'est absolument pas recommandé) il faut passer par le code natif.

Merci pour ces informations. Avec l'instruction :

Code:

---

Runtime.getRuntime().MaxMemory()

---

mon GS2 retourne 134 Mo, ce qui explique bien les plantages obtenus. Il est donc bien nécessaire de réduire la taille des bitmaps et de modifier mes algorithmes de changement de dalles.

Pour autant, pouvez-vous m'expliquer pourquoi, dans le cadre cité plus haut, l'instruction :

Code:

---

Canvas Cnv = new Canvas(bitmap);

---

entraîne un plantage (plutôt une exception dans le cadre d'un try ... catch) et surtout comment faite vous mettre à jour la bitmap plutôt que la "réallouer" ?

Merci de votre aide.

Pierre

Tout est dans la doc de Bitmap
En particulier la fonction setPixels()

Citation:

---

Envoyé par nicroman

Tout est dans la doc de Bitmap
En particulier la fonction setPixels()

---

Je ne vois vraiment pas comment je pourrais remplacer un morceau de carte par un autre avec setPixels dont la fonction est : "Replace pixels in the bitmap with the colors in the array" ???

Utiliser un getPixels ?, mais il me faut un autre bitmap où aller chercher ces pixels. Cela ne résout pas le problème d'occupation mémoire car, à un moment donné, il faudra bien que j'aie un autre bitmap contenant ma nouvelle carte.

Merci de votre aide.

Pierre