Ne dessiner que les pixels qui changent

**thierryler** · 19/11/2010, 09h57

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 :

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

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 :

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

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 :

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

1
2
3
4
5
6
7
 
while(true) {
  bougePositions(pixels) // faite bouger les pixels
  //repaint()
  repaintOnlyChanged() // un truc comme ça...
  Thread.sleep(millis)
}

**adiGuba** · 19/11/2010, 10h13

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 :

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

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.

**thierryler** · 19/11/2010, 10h18

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

Explique-moi, quand je fais

Code :

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

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 :

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

1
2
 
Rectangle bounds = g.getClipBounds();

**Chatanga** · 19/11/2010, 10h26

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.

**thierryler** · 19/11/2010, 10h29

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

**adiGuba** · 19/11/2010, 10h47

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

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.

Envoyé par thierryler

Par contre je ne vois pas bien à quoi sert

Code :

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

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

**thierryler** · 19/11/2010, 10h57

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 :

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

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 :

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

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

puis

Code :

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

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
}

**fraco** · 19/11/2010, 12h34

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 ?

**thierryler** · 19/11/2010, 13h12

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

**adiGuba** · 19/11/2010, 13h30

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

**thierryler** · 19/11/2010, 13h38

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.

**sinok** · 19/11/2010, 16h47

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.

**tchize_** · 19/11/2010, 17h18

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

**sinok** · 19/11/2010, 17h35

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.

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.

**bouye** · 19/11/2010, 23h15

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 ?

**adiGuba** · 20/11/2010, 17h35

@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++

**bouye** · 20/11/2010, 21h29

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.