2012-07-08 5 views
0

J'ai remarqué un comportement étrange lors de l'écriture de quelques pixels dans le tampon de pixels obtenu en utilisant ANativeWindow_lock(). Supposons que je veux tracer une ligne de (0 | 0) à (320 | 240). Pour ce faire, j'appelle ANativeWindow_lock() avec les limites des paramètres fixés à quelque chose comme:Écriture de quelques pixels seulement pendant ANativeWindow_lock()

ARect b; 
b.left = 0; 
b.top = 0; 
b.right = 320; 
b.bottom = 240; 

Ensuite je dessine ma ligne en utilisant l'algorithme de Bresenham dans la mémoire tampon de pixels. Comme la ligne n'est pas droite, je n'ai qu'à modifier très peu de pixels dans le buffer de pixels obtenu à partir de ANativeWindow_lock(). C'est principalement un pixel par ligne de balayage dans le tampon de pixel qui est modifié par mon implémentation de Bresenham. Le reste du tampon de pixels reste intact.

Maintenant vient le comportement étrange: Quand j'appelle maintenant ANativeWindow_unlockAndPost() tous les pixels que je n'ai pas modifiés contiennent souvent des couleurs aléatoires et non la couleur qui a été dessiné pour la dernière fois. Cela me rend confus: Pourquoi ces pixels ne conservent-ils pas les valeurs de couleur que je leur ai écrites en dernier?

Prenons le cas suivant pour comprendre ce qui se passe:

  1. totalité de l'écran bleu.
  2. Remplissez l'intégralité de l'écran avec du rouge.
  3. Dessinez une ligne diagonale sur l'ensemble de l'écran.
  4. Maintenant, les parties du tampon de pixels que je n'ai pas modifiées apparaissent soudainement en BLEU bien que j'ai effacé l'écran pour qu'il soit complètement ROUGE juste avant de dessiner la ligne.

Est-ce que quelqu'un a une explication pourquoi cela se passe-t-il? Le seul moyen de contourner cela est de toujours modifier TOUS les pixels du buffer de pixels obtenus à partir de ANativeWindow_lock(). Mais bien sûr, cela signifie souvent beaucoup de frais généraux si seulement quelques pixels doivent être tirés, par exemple dans le cas d'une ligne!

Testé sur Android 2.3 et 3.1.

Des idées?

Merci

Répondre

0

David Turner a expliqué ce qui se passe sur la liste de diffusion NDK Android: Android utilise en mémoire tampon double ou même triple et c'est la raison pour laquelle on ne peut pas faire des hypothèses sur ce qui est dans la mémoire tampon de pixels lors de l'appel ANativeWindow_lock() et doit toujours actualiser tous les pixels du rectangle qui doit être mis à jour.

Questions connexes