JScrollPane, JAVA2D : problème d'intéractivité

Bonjour,

Je vous définis rapidement le problème auquel je suis confronté :

Context
J'effectue actuellement des tests concernant l'utilisation du composant JScrollpane. Ce dernier contient un JPanel dans lequel, via l'utilisation d'un Graphic2D et java2D, je réalise différents dessins comparables à des matrices colorées.

Problème
Je rencontre un problème lorsque le jeu de donnée à représenter devient conséquent. Le temps de génération de la zone graphique comprise dans le JSrollpane devient important (Test : ~1.3 sec). Cela nuit fortement à l'intéractivité logiciel, car à chaque fois que la scroll est déplacée le graphique se raffraîchit. Or, selon mon analyse, le problème réside dans le fait que l'ensemble de la zone graphique est générée (alors que seul une partie minime est affichable lorsque l'on considère la résolution du moniteur).

De façon imagée si l'on considère que la partie visible comprise dans le JScrollPane [---] se situe entre les crochets :
...**********[---]**********...

Etude de Solution
La résolution de cette problématique, serait de faire en sorte que seule la partie visible de la zone graphique contenue dans le JSrollPane soit dessinée via la méthode paintComponent. Pour en revenir à l'image proposée ci-dessus, nul besoin de générer les zones représentées par des ***.

Pour cela j'entrevois la possibilité d'effectuer la corrélation entre les paramètres du JScrollPane permettant de définir la zone affichée (bornes de la scroll) et mon algorithme d'affichage contenu dans la méthode PaintComponent.
Ainsi seule une partie de mes structures de données seraient représentées graphiquement.

Je me souviens avoir implémenté ce procédé en SWT, mais dans ce cas je pense inclure un Zoom et je redoute que l'évolutivité du code soit mise à mal si j'utilise cette méthode, cependant je n'ai aucune autre solution.

Je souhaiterais donc avoir votre avis, car je suis persuadé que ce problème doit classiquement être rencontré en programmation graphique.

En espérant avoir été le plus clair possible et en vous souhaitant une très agréable fin de semaine, je vous remercie d'avance.

Bonjour

Je suppose que les opérations de dessin sont effectués dans le paintComponent de ton composant. Or swing met à disposition un moyen pour éviter d'avoir à redessiner l'intégralité d'un composant. En effet il existe une méthode repaint précisant un rectangle dans lequel le composant doit être redessiné. Cette version de repaint est utilisée par le JScrollPane afin de limiter les opérations de dessin. Ce repaint fait en sorte de déterminer une zone de clip spécifique sur les Graphics qui seront utilisés dans le paintComponent. Pour récupérer ce Rectagle il te suffit d'appeler la méthode getClip de tes Graphics. Tu auras alors de fait la zone du composant qu'il faut redessiner. Ceci devrait largement améliorer les perfs de ton composant.

Cf http://www.oreillynet.com/onjava/blo...g_optimiz.html

Wow, c'est impressionnant le changement de vitesse lorsque c'est optimise et que ce ne l'est pas. Faut croire que regarder pour une intersection entre 2 rectangles est beaucoup plus rapide que de dessinner un rectangle.

Mais j'ai quelques interrogations.

Dans l'exemple qui est donné lorsqu'on suit le lien donné par Sinok on voit que la personne a optimisé le code en utilisant getClip (dans Graphics). Ainsi, il peut déterminer la zone du graphic qui sera affiché à l'écran. Puis, lorsqu'il vient pour dessinner les rectangles il regarde premièrement s'ils intersectent la zone affiché à l'écran. L'optimisation vient du fait que vérifier un intersect est plus rapide que de dessinner un rectangle. Pour cette partie ca va.

1. Le Graphics associé à un JComponent est bien exactement de la même grosseur que son JComponent? et lorsque vient le temps de l'affiche Java détermine quel partie de ce Graphics doit être affiché et affiche juste cette petite partie?

2. Il existe également des méthodes repaint qui spécifie un rectangle à dessinner. Ce rectangle qui est spécifié est-ce qu'ils correspont à une aire sur le Graphics du JComponent? Ainsi, si la zone qu'on a spécifié à redessinner de cette manière n'intersecte pas la zone affiché alors on aura rien changé du tout?

Bonjour,

Ayant eu un peu de temps pour faire un petit test d'implémentation, je peux dire que cette alternative qui m'était inconnue, est parfaitement adaptée à mon problème.

Je gagne de 600 à 800 ms par rafraîchissement, épatant !!

Merci beaucoup à toi Sinok, bonne continuation.