Ne dessiner que les pixels qui changent

Bonjour à tous,

J'ai un JPanel, disons de 300x300 pixels. Dans ce panel, je dessine une série de pixels définis dans un tableaux.

Code:

---

1 2 3 4 5 6 7 8 9

class Pixel { int x int y Color color boolean changed // si x et y n'ont pas changé }   List<Pixel> pixels = ...

---

Pour dessiner mes pixels dans mon panel, j'utilise la méthode repaint() :

Code:

---

1 2 3 4 5 6

while(true) { bougePositions(pixels) // faite bouger les pixels repaint() Thread.sleep(millis) }

---

Or Ca va donc redessiner tout mon écran a chaque boucle. Or plus j'augmente la vitesse de la boucle, plus mon écran scintille. Du coup je cherche la bonne méthodologie pour ne redessiner que les pixels qui ont changé...

Code:

---

1 2 3 4 5 6 7

while(true) { bougePositions(pixels) // faite bouger les pixels //repaint() repaintOnlyChanged() // un truc comme ça... Thread.sleep(millis) }

---

Salut,


Tu peux utiliser repaint(x, y, width, height) pour déterminer la région à repeindre.

Dans ton paintComponent() il faut ensuite récupérer le "ClipBounds" afin de connaitre la région à redessiner :

Code:

---

1 2 3 4 5

@Override protected void paintComponent(Graphics g) { Rectangle bounds = g.getClipBounds(); ... }

---

a++

PS : Il y a une raison à utiliser un JPanel ? En général un JPanel est prévu pour recevoir des composants... cela ne semble pas être ton cas.

J'ai utilisé un jpanel faute d'une meilleure idée. Je suis preneur de tous les conseils.

Explique-moi, quand je fais

Code:

---

1 2 3

... repaint(45, 56, 10, 10);

---

Ca va vider une zone de 10px de large dont le coin gauche est à (45,56) ? puis ça lance paintComponent() et ensuite ça marche comme d'habitude ?

Par contre je ne vois pas bien à quoi sert

Code:

---

1 2	Rectangle bounds = g.getClipBounds();

---

Citation:

---

Envoyé par thierryler

Or Ca va donc redessiner tout mon écran a chaque boucle. Or plus j'augmente la vitesse de la boucle, plus mon écran scintille. Du coup je cherche la bonne méthodologie pour ne redessiner que les pixels qui ont changé...

---

Le double buffering étant activé par défaut sous Swing, ça ne devrait pas clignoter. Optimiser le rafraîchissement ne devrait rien y changer. Je pense que ce clignotement a une autre origine, mais sans le détail de ton code, difficile d'être plus précis.

En fait j'utilise abusivement le terme "clignotement"

Dans mon algo, je dois être capable d'afficher mon ecran le plus vite possible, sachant qu'il me faut plusieurs millions d'affichage avant que le programme se termine. Donc en vrai je ne fais pas de sleep, et là c'est le drame...

Citation:

---

Envoyé par thierryler

J'ai utilisé un jpanel faute d'une meilleure idée. Je suis preneur de tous les conseils.

---

Ben hériter directement de JComponent...

Citation:

---

Envoyé par thierryler

Ca va vider une zone de 10px de large dont le coin gauche est à (45,56) ? puis ça lance paintComponent() et ensuite ça marche comme d'habitude ?

---

Non cela ne fait rien de particulier : comme le repaint() cela ne fait qu'appeller la méthode paintComponent().
La seule différence c'est que cela passe en plus les coordonnées de la zone à redessiner.

Citation:

---

Envoyé par thierryler

Par contre je ne vois pas bien à quoi sert

Code:

---

1 2	Rectangle bounds = g.getClipBounds();

---

---

Ben cela sert à récupérer les coordonnées de la zone à dessiner.

Avec repaint() cela correspondra à toute la zone de ton composant.
Avec repaint(x,y,width,height) cela correspondra uniquement à la zone (x,y,width,height).

Donc dans le code de ton paintComponent(), tu dois récupérer cela pour ne dessiner que ce qui est utile...


a++

Ok, donc dis moi si j'ai bien compris.

Dans le cas de mes pixels qui se déplacent, prenons un pixel en particulier :

Code:

---

1 2 3

// oldX, oldY, newX, NewY pixel = new Pixel(10, 10, 11, 11);

---

Dans cet exemple je veux que mon pixel se déplace d'un px en bas et d'un px à droite.

Si je comprend bien, je dois donc faire :

Code:

---

1 2 3

repaint(10, 10, 1, 1) // Ancien à effacer repaint(11, 11, 1, 1) // Nouveau à dessiner

---

puis

Code:

---

1 2 3 4 5 6 7 8 9

protected void paintComponent(Graphics g) { // fond noir Rectangle bounds = g.getClipBounds(); if(old) g.draw(carre noir) // 10,10 else g.draw(carre blanc) // 11 }

---

Citation:

---

je dois être capable d'afficher mon ecran le plus vite possible, sachant qu'il me faut plusieurs millions d'affichage avant que le programme se termine.

---

Simple curiosité : qu'est-ce que c'est comme application ? quelqu'un va regarder sur l'écran ces millions d'affichage ?

Ce sont des particules qui se déplacent. Il faut un grand nombre de particules pour que les résultats soient intéressants.

J'ai déjà fait la version full-memory avec affichage final du résultat des expérience, mais c'est chiant d'attendre devant un écran noir pendant 2 heures...

Je pense que via se question, fraco voulait savoir les raisons pour lesquels il faut repeindre obligatoirement à chaque pixel modifié...

Un repaint() uniquement tous les 50/100 ms doit être amplement suffisant non ?

a++

Ah oui bonne question.

Dans mon algo, quand un pixel atteint le bord de l'univers, il devient immobile. Donc il n'y a plus à le dessiner. Et quand un pixel atteint un pixel immobile, il devient également immobile par agglomération. Donc en fait, plus ça va et plus il y a de pixels immobiles, qu'il est donc inutile de dessiner de nouveau, d'autant qu'ils sont vraiment nombreux...

En outre, je souhaite voir les particules se déplacer case par case, sans qu'elles fassent des bonds... C'est d'autant plus important quand les particules interagissent entre elles.

Commence par faire tes calculs dans un thread séparé et en parallèle déclenche un repaint de ton composant toutes les X millisecondes ou tous les x calculs réalisés. Honnêtement, un décalage d'un pixel est complètement négligeable dans ce genre de cas. En soit les représentions graphiques sont de toute façons biaisées et fausses.

+1: le plus propre est de dessiner à fréquence continue (50 images par secondes, donc toutes les 20ms) plutot que de vouloir redessiner tous les mouvements.

De toute façon swing a une certaine tendance à agréger les demandes de repaint si celles si sont trop proches les unes des autres. De fait si tu appelle n fois repaint en moins de x millisecondes, une seul appel à paint en résultera.

Citation:

---

The repaint() method is smart enough that if multiple repaint requests pile up in the AWT EventQueue faster than the event dispatch thread can process them, they will be coalesced, i.e., merged, into a single request for efficiency. If the repaint areas for the multiple requests are not exactly identical, the new merged request will cover a rectangular area that encloses the union of both of the original requested areas.

---

Petite précision : il n'y a aucune différence fondamentale à hériter de JComponent ou de JPanel pour créer un nouveau composant.

• JComponent n'est pas opaque.
• JPanel est opaque.

Et c'est tout. Mis à par son nom, il n'y a rien de particulièrement spécial dans JPanel qui empêche de l'étendre.

Si le nombre de particules est si important et la performance aussi, ne faudrait-il pas mieux aller voir du coté de JOGL, non ?

@bouye : la différence est surtout d'un point de vue "logique" : si on crée un composant perso autant hérité directement de JComponent...

De plus il y a une seconde différence : cela évite la création d'un FlowLayout inutile ;)

a++

C'est bien cela. Attention à ne pas tomber dans les travers du manteau blanc et du blanc manteau en faisant de la discrimination abusive.

Personne ne semble avoir pointé que son clignotement vient potentiellement de l'usage de sleep() dans une boucle qui semble être exécutée dans l'EDT. De même, outres les optimisations de base (repaint(x,y,w,h) + collision), nous ignorons s'ils dessine directement à l'écran ou offscren (et si c'est le cas dans une image compatible ou pas ?). Quand au fait de devoir avoir un taux de rafraichissement rapide et constant, il peut être interressant d'aller voir dans les forums Java Game APIs & Engines sur http://www.javagaming.org/index.php#4 pour des indications sur comment faire ce genre de chose, voir même comment créer un repaint manager perso.

Petite précision, en vrai je n'utilise pas de sleep. Je laisse la boucle aller aussi vite que possible.

J'ai trouvé ça sur jogl : http://info-rital.developpez.com/tut...pengl/opengl1/

Citation:

---

Envoyé par thierryler

Petite précision, en vrai je n'utilise pas de sleep. Je laisse la boucle aller aussi vite que possible.

---

Ce qui n'est pas forcément mieux justement si elle tourne durant l'EDT.

En vrai, ma boucle c'est juste

Code:

---

1 2 3 4

while(!end) {   }

---

Mais là je vais changer un peu pour mettre un affichage de 50fps en espérant que ça ne fera pas faire de saut à mes particules.

Je me demande si je ne vais pas laisser une trainée derrière la particule.

Le problème ici c'est que tu réalises des calculs dans le thread destiné au dessin (aka l'EDT). de fait ça bloque ce thread de façon momentanée, et de fait tu n'as aucune façon d'être sur que le composant va se redessiner au moment voulu, vu que tu bloques le thread destiné à ce fait par tes calculs. En effet l'appel à repaint ne déclenche pas directement le dessin du composant. Il ne fait juste que mettre en file une demande de rafraichissement du composant dans l'EventQueue. Le rôle de l'EDT étant de consommer l'EventQueue dès qu'il est disponible, or avec ta boucle tu ne lui rend pas vraiment la main. Donc il galère un peu à dessiner ton composant.

Cf le tutoriel suivant: http://gfx.developpez.com/tutoriel/j...ing-threading/

Oui je comprend très bien. En fait j'étais moi-même arrivé à une conclusion équivalente sans réussir à mettre des mots dessus. Du coup faire du 50fps ça devrait bien résoudre mon problème, en plus de ne dessiner que la zone qui change. Et évidement je vais faire mon calcul de position des particules dans des threads séparés.