Android : GLSurfaceView & OpenGL ES - crash sur appareil mais pas emulateur

[heldorhn]

Bonjour,

Je me trouve face à un problème qui esquive mes moyens de débugage.

J'ai une GLSurfaceView qui affiche un Bitmap en 2D créé de manière programmatique. C'est un petit jeu donc les données sont calculées dans un moteur physique à part.

Avec l'émulateur le programme fonctionne sans trop de problèmes (excepté que mon PC transpire un peu).

Lorsque je lance le programme sur un appareil réel le programme tourne parfaitement quelques secondes, se met doucement à saccader puis l'application crash sans donner aucun message d'erreur.

La même chose se produit avec le mode continu qu'avec le mode when dirty (setRenderMode() RENDERMODE_CONTINUOUSLY ou RENDERMODE_WHEN_DIRTY) mais elle se produit plus lentement avec le mode when dirty.

J'en déduis que c'est un problème qui est lié à l'évolution des frames, cependant il ne provient pas du moteur physique car tout fonctionne très bien (mais pas assez vite) quand je test avec une ImageView sans passer par des librairies OpenGL ES.

Voilà, pour le dépannage ça coince parce que j'ai aucune info de la part d'Android Studio que ce soit en mode play ou debug...

Est-ce que quelqu'un aurait une idée de la direction dans laquelle chercher ?

Le cas échéant, est-ce que quelqu'un connais un endroit ou trouver une bonne documentation sur OpenGL ES ?

Je trouve tout le temps les mêmes tutos sur la mise en place des classes mais pas sur des sujets plus précis comme par exemple la manière idéale d'échanger des informations entre ce qui tourne dans le GPU et le programme principal.

Merci d'avance à celui ou celle qui saura m'éclairer !

Held
-----

[umfred]

tu as regardé la doc sur https://developer.android.com/guide/...raphics/opengl ?

[heldorhn]

J'ai lu ce qu'ils fournissent sur Android Developer, quelque chose m'a peut-être échappé mais je peine à savoir quoi. Je vais relire ce qu'il y a sur le lien que tu m'as donné, merci.

Mise-à-jour par rapport à ce que j'ai écris plus haut : Le crash se produit aussi sur l'émulateur mais au bout de beaucoup plus de temps et il se produit parce que la RAM du PC se sature petit à petit au fil du temps de fonctionnement de OpenGL ES (j'entend par là le temps pendant lequel fonctionne le thread du Renderer de la GLSurfaceView).

Quand ça crash j'ai ~70% du CPU qui est utilisé et 97% de la RAM alors qu'au début tout est fluide.

Il y a quelque part quelque chose qui grossi sans se remettre à 0 ou un truc du genre.

[vgondr98]

Bonjour,

Ce lien fournit un tuto pour détecter les fuites mémoires :
https://instabug.com/blog/how-to-fix...-memory-leaks/

[A voir en vidéo sur Futura]

[heldorhn]

Bonsoir,

@vgondr98 : Merci pour le tuto, il m'a aiguillé vers la solution.

Le problème est résolu. Pour que le topic ne serve pas à rien, voici un résumé en quelques mots :

J'avais une méthode de chargement de texture qui était appelée dans la méthode OnDrawFrame de la GLSurfaceView.
Cette méthode contenait les instructions suivantes :

        // generate one texture pointer
        gl10.glGenTextures(1, textures, 0);

        // ...and bind it to our array
        gl10.glBindTexture(GL10.GL_TEXTURE_2D, textures[0]);

        // create nearest filtered texture
        gl10.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_NEAREST);
        gl10.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);

        // Use Android GLUtils to specify a two-dimensional texture image from our bitmap
        GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, frame, 0);

Apparemment, les deux premières lignes de code provoquaient l'accumulation de textures dans un byte array.
J'ai appeler ma méthode à la création de la GLSurfaceView et je n'ai laissé dans la méthode OnDrawFrame que GLUtils.texImage2D(GL10.GL_TEX TURE_2D, 0, frame, 0);.

De cette manière seule une seule texture est stockée, elle est mise à jour à chaque requête de dessin et en conclusion ma RAM ne part plus en cacahuète (son % d'utilisation reste stable).

A+!