Swing et animation de polygones tres lente

Bonjour à toute la communauté.

Je me permet de vous soumettre un problème que j'ai avec mon petit logiciel de dessin vectoriel. Je vais tenter d'être à la fois bref et précis.

Je suis développeur amateur et je travaille depuis quelques mois sur un petit logiciel de dessin vectoriel dont je suis assez fier puisqu'il permet déjà de créer, modifier, manipuler, copier/coller, colorer des polygones/generalPath, à l'unité ou en groupe (via une arborescence de "noeuds de scenes" classique "groupes/sous-groupes" et "polygones/generalPath" représentée par un JTree). Il permet d'enregistrer et ouvrir les dessins ainsi obtenus dans un format que j'ai crée proche du SVG (simplifié). Enfin bref pas mal de boulot pour un amateur, d'autant que je n'utilise pas de librairies externes (style "batik").

Mon gros problème c'est que les animations qui s'effectuent lorsqu'on manipule un ou plusieurs polygones dans un graphisme de plusieurs polygones sont tres tres lentes. Pour m'en convaincre, j'ai créer differents "dessins" comprenant de plusieurs dizaines à plusieurs milliers de polygones, et je tombe à 5 FPS quand j'affiche 6800 polygones.

Je suis sous Swing et mes graphismes s'affichent dans un JPanel. Le processus qui s'effectue est des plus simple, c'est celui que l'on trouve dans la plupart des exemples sur le web: les evenements de souris (MouseEvent) engendrent des calculs sur les polygones (position, rotation, redimension) puis enchainent sur un repaint() du JPanel. La méthode paintComponent de ce JPanel appelle les méthodes "Dessiner" de mon SceneManager et de mon DebugSceneManager, qui contiennent respectivement les polygones/groupes et méthodes affiliées pour l'un, une liste des polygone selectionnés pour l'autre. Pour info, le DebugSceneManager sert à mettre en évidence, par dessus la "scene", les polygone selectionnés, ceux sur lesquels on agit.

Clairement, et peut-être sont-ce là mes erreurs, je n'utilise pas de Thread séparé, pas de BufferStrategy, pas de BufferedImage... Le "repaint" du JPanel est effectivement une opération "lourde" dans la mesure où le SceneManager redessine toute l'arborescence de la scene, polygone apres polygone...

J'ai essayé de nombreuses astuces, optimisé au mieux mon code, pourtant les repaint() qui s'effectuent "en rafale" en réaction aux mouvement de souris, sont lent, en particulier dans un gros "dessin".

Alors j'aimerais beaucoup, si l'un de vous se sent le coeur de m'éclairer, qu'on m'explique quelle est la meilleure technique pour afficher et animer un nombre conséquent de polygones dans Swing? Est-ce simplement possible? Est-ce qu'il y a une astuce??? Je n'ai JAMAIS autant galéré, fait d'essais... Et étant donné le temps que je perd à chaque fois... Si on pouvais m'aider ce serait super!!!

Merci d'avance à ceux qui prendront le temps de me lire.

Christophe.

PS: Deux images de mon prog:

Pièce jointe 261069
Pièce jointe 261072

Pour illustrer l'affichage du "DebugSceneManager" (ce sont les polygones selectionnés et affichés en bleu)
Pièce jointe 261088

Citation:

---

Envoyé par kribsx

sont-ce là mes erreurs, je n'utilise pas de Thread séparé, pas de BufferStrategy, pas de BufferedImage... Le "repaint" du JPanel est effectivement une opération "lourde" dans la mesure où le SceneManager redessine toute l'arborescence de la scene, polygone apres polygone...

---

Donc en gros, ton paintComponent() consiste a parcourir intégralement la liste de tes polygones et a tous les dessiner directement sur l'ecran ?

Parmi les premières optimisations progressivement envisageables (vu qu'on a pas vu de code difficile de dire ce que tu utilises déjà) :

1. Ne pas dessiner les trucs complètement en dehors de la zone de clip du graphics.
2. Lors des réactions aux clics de la souris, invoquer repaint(x, y, w, h) plutôt que repaint() -> Ne pas dessiner les trucs complètement en dehors de la zone de clip (devenue restreinte) du graphics.
3. En cas d'animation, invoquer repaint(x, y, w, h) plutôt que repaint() -> Ne pas dessiner les trucs complètement en dehors de la zone de clip (devenue restreinte) du graphics.
4. Dessiner dans une BufferedImage qui sert de tampon offscreen -> composer ce tampon a l’écran.
5. Optimiser le dessin dans le tampon -> calculer la zone de clip -> Ne pas dessiner les trucs complètement en dehors de la zone de clip du graphics du tampon.
6. Mettre en place un système de simple-thread :
   
   1. Le thread qui sert a dessiner dans le tampon et invoquera repaint(...)
7. Mettre en place un système de double-thread :
   
   1. Le thread qui sert a dessiner dans le tampon.
   2. Le thread qui invoque repaint(...) pour dessiner le tampon a l’écran a un taux de rafraichissement fixe.
8. Explorer BufferStrategy etc.

Salut,

Je te conseille de jeter un coup d'oeil à la bibliothèque open source Piccolo2D qui met en oeuvre ce genre de choses. J'ai pu afficher des dizaines de milliers d'objets, et groupes d'objets, avec animation, tranformées affines, etc. Le code de sélection est également intéressant à regarder. J'ai rencontré un peu plus de difficultés avec des images bitmap (il n'y a pas de gestion de double tampon) mais j'ai pu le régler avec du resampling dynamique (en quelque sorte en gérant un double-buffer avec cache au niveau de l'objet), le zoom étant légèrement impacté au delà de 10000 objets, mais le pan, les animations, les rollovers restent très fluides.

Merci à vous deux pour vos réponses. :D

Bouye: Aucun problème à transmettre tout ou partie du code, mais la partie "problématique" est tellement grosse, divisée en plusieurs parties (JPanel, DebugSceneManager, SceneManager) que je me suis dit que je n'allais pas d'entrée "imposer" la lecture de tout ce bazar à ceux qui prendraient la peine de me lire. J'ai apéro ce soir mais je vous pose ça tout à l'heure sans problèmes.

Pour ce qui est de la zone de clip j'ai effectivement limité le dessin à une zone visible, mais dans le "Draw" du SceneManager, pas dans le repaint() du JPanel. En fait j'ai pensé que le JPanel ne connaissait pas l'emplacement des polygones et par conséquent j'ai crée une méthode pour détecter si le polygone possède un point visible dans la vue ou pas. En plus du fait que ça n'affiche pas les rectangles plus grands que la vue (par exemple), ça ne m'a fait gagné que 2 FPS. Je vais donc essayé les astuces que tu m'as donné. Par contre il m'avait semblé avoir compris que BufferStrategy n'etait pas adapté à Swing puisqu'il fallait utiliser un "Canvas", qui serait un composant AWT, et que le JPanel est automatiquement "double-buffer". Mais alors là c'est des trucs qui me dépassent :oops:. Merci

joel.drigo: En fait j'ai fait ce programme sans planifier quoi que ce soit, il a évolué doucement au fil de mes envies. C'est à dire que je n'avais même pas envisagé au début lui faire faire tout ce qu'il fait aujourd'hui. Donc en fait je me retrouve avec un "gros" programme (pour moi lol) sur les bras et je me vois mal reprendre à zéro maintenant, et mettre à la poubelle toutes ces classes et méthodes que j'ai crée moi même. Même si effectivement je sais pertinemment qu'il y a de nombreuses alternatives tres performantes, et qui ont déjà tout ce que je pense faire plus tard. Faut dire aussi que je prends plaisir à faire tout ça moi même, ça m'a permis et me permet de comprendre un peu tout ça de l'interieur, par la pratique. En principe je me suis toujours démerdé seul à partir d'exemples et autres tutos, mais là c'est vrai que je bloque niveau optimisation "graphique". Faut dire que je ne suis pas du tout du métier, ni même étudiant dans le domaine. Me manque sûrement certaines bases, une bonne formation, même si je crois pas être au niveau zéro. Pour info je suis dans le BTP je joue au développeur sur mon temps libre :mouarf:. Merci pour l'astuce. Sinon, aurais-tu un lien ou un tuto , ou saurais-tu m'en dire plus sur le principe du cache au niveau de l'objet?

PS à vous deux: Je viens de remarqué, suite à la réponse de Bouye sur la "zone de clip", que lorsque j'applique un zoom inférieur à 100% (je dézoome quoi...), le FPS regrimpe tres nettement, malgré les 6800 polygones!!! J'obtiens 32 FPS en réduisant la taille à 1/10 (Zoom 10%)!!! Dans ma méthode zoom je redimensionne les polygones mais également le JPanel qui les contient. J'en déduis donc que la taille de la zone de repaint() à une influence énorme. Me reste à essayer les astuces de Bouye pour voir ce que je peux obtenir comme ça, parce que bon c'est difficile de faire du dessin vectoriel dans un espace de 100X100 pixels :aie:!!! Merci à vous deux je reviens plus tard je poste mon code et je vous tiens informé sur l'évolution de mon problème qui me casse les #### et me bloque depuis trop longtemps!

Sans tout réécrire depuis zéro, tu peux refactoriser certaines parties, ajuster, intégrer en partie des idées, petit à petit réécrire certaines parties (tout dépend de ta vision à long terme sur ton projet).
Par exemple, je pense à ce que tu écris :

Citation:

---

Envoyé par kribsx

j'ai crée une méthode pour détecter si le polygone possède un point visible dans la vue ou pas.

---

Dans Piccolo2D, comme très classiquement dans ce genre de système, tout node (polygone ou autre) à des bounds (local, global), qui sont mis à jour lors de la modification/création du node (du polygone le cas échéant), la modification des bounds d'un node est remontée à son parent pour que ses bounds soient mise à jour. Ensuite, au lieu de chercher si un point (de path) est dans le clip ou pas, Piccolo2D teste rapidement l'intersection avec les bounds. Et seulement ensuite, il y a éventuellement un test sur chaque point. Ainsi ça élimine très rapidement des milliers de polygone hors clip quelque soit leur complexité et leur nombre de points. De même, le processu de paint est délégué à un painter, qui empile les clips et les bounds, ce qui donne en résultat une sorte de test ressemblant à du quadtree, qui optimise également le traitement. Voilà une idée qui me semble normalement pas trop difficile en théorie d'implémenter sans tout réécrire, quelque soit ton archi actuele par ailleurs (partiellement si nécessaire : au moins tenir à jour des bounds de polygone pour faire un premier filtre rapide).

joel.drigo: Effectivement, sans me contenter d'utiliser Piccolo2D bêtement, je vais l'étudier et m'en inspirer. Merci.

A noter qu'il faudra faire la distinction entre les bounds logiques et les bounds factuelles. Si mes souvenirs sont bons par exemple en Java2D le stroke est tout le temps placé sur le milieu du chemin (JavaFX et d'autres libs graphiques permettent de le placer au milieu, sur le bord extérieur ou sur le bord intérieur). Donc la bounds factuelle est plus large de 0.5 strokeWidth de chaque coté et ce dans chaque direction (= 1 strokeWidth sur la largeur et 1 strokeWidth sur la hauteur). De plus si tu implémentes des effets graphiques tels que des blurs ou ombres portées, alors ça rajoute d'autant plus d'espace autour des bounds logiques de la forme. Donc si tu te contentes de la bounds logique, tu vas être amené a avoir des artéfacts et autres trucs déplaisants dans ton rendu.

Le but est de découpler ton code un maximum de ton JPanel pour le rendre plus facilement adaptable a un graphics tiers quelconque (provenant soit d'un JPanel, soit d'un tampon, soit d'une imprimante, soit d'un renderer/exporteur PDF, etc.) mais aussi de pouvoir modulariser le code si besoin pour effectuer des optimisations si nécessaires.

Ok je crois que j'ai pigé le truc:

il faut que je groupe les polygones dans differentes BufferedImage, comme ça au lieu de dessiner 6000 polygones à chaque "boucle", je dessine une seule fois les polygones dans differents BufferedImage, et ne redessine que les changements à chaque boucle. J'utilise les BufferedImage comme des calques autogérés et déjà je gagnerais en performance je pense. Apres un premier essai je pense être sur la bonne voie :zoubi:.



bouye: oui j'ai pu observer ce détail à priori vu la simplicité de mon programme les quelques pixels "de marge" ne se voyaient pas. J'avais anticipé le système de Bounds et de zone de Clip en ajoutant une marge de fait. :mouarf: La je test avec des calques de la taille du plan (et du jPanel).

Quand je vois un truc comme Piccolo2D je me dit que j'ai de la marge c'est une sacrée mécanique.

Ca peut aider mais c'est aussi une énorme consommation de mémoire supplémentaire. Par exemple dans JavaFX qui utilise son propre algo de graphe de scène, on n'active le caching bitmap en général qu'en cas d'animation ou de déplacement dans la scène car si c'était activé tout le temps pour tous les nœuds la consommation mémoire de l'UI exploserait encore plus mais d'un autre coté ça améliore effectivement les perfs (puisque comme tu dis une seule bitmap à composer c'est plus simple que de dessiner plein de polygones). Si ton algo de détection des bounds et/ou quadtree est bien implémenté et donc que le réaffichage se produit rarement, cette amélioration ne devrait pas vraiment se voir par contre. Dans le cas ou le contenu de ton rendu est modifié (animation, scroll via les barres de défilement), là oui ça aidera. Mais il te faudra du coup donc utiliser plus de mémoire et surtout bien veiller à synchroniser l'état de tes caches et de tes polygones (quand tu changes la couleur ou un attribut par exemple). Grouper les nœuds/polygones par couche/calque/groupe fait qu'effectivement tu as moins de bitmaps donc moins de mémoire utilisée mais tu gagnes des perfs quand même. Par contre du coup vérifier les changements d'états des polygones enfants est d'autant plus critique pour bien mettre le cache à jour.

Pour l'instant j'ai crée une classe "Painter" qui gere désormais l'affichage de la scène via une ou plusieurs BufferedImage. A chaque changement de sélection de polygone (puisqu'on sait que les polygones qui seront en mouvement seront ceux sélectionnés), le "Painter" sépare la scene en plusieurs "calques" automatiquement, ceux qui sont fixes et ceux qui afficheront des mouvements. Ainsi quand je déplace/redimensionne/pivote ma sélection seuls les calques en mouvement ne sont redessinés, la partie fixe simplement réaffichée, sans être redessinée.

C'est nettement plus rapide dans les mouvements!! Mais je dois pouvoir améliorer encore ça en réduisant la taille des calques aux Bounds de ce qu'ils affichent.

J'ai bien compris le principe maintenant il y a moyen de faire des super trucs :mouarf:.

Je met le sujet en résolu même s'il y a de nombreuses optimisations à faire encore!