Animation sans timeline & Co

Je souhaite obtenir une animation simple pour commencer : une ligne qui tourne sur elle même...

Lorsque j'essaie avec un Canvas ou un node, la ligne s'affiche et une routine tourne sans effet direct. Lorsque celle-ci se termine, l'affichage est modifié comme "prévu" mais il manque les étapes intermédiaires. J'ai parcouru un peu le web et ai essayé de faire un peu gaffe avec les threads (appel depuis le bon thread) mais sans succès manifestement d'où ma question : Est-il possible d'avoir l'équivalent swing du "repaint()" en JFX ? Parce les animations (celles de JFX), ça fonctionne mais ce n'est finalement pas ce que je recherche...

Voilà! Si vous avez un tuto expliquant ça, je suis preneur.

Merci

Chak

Oui et non...

Oui, si tu utilises Canvas car Canvas contient du contenu "mort" (dead pixels) qui n'evolue que quand tu dessines explicitement dedans. Donc il faut recréer un système similaire a ce qui existe en AWT/Swing/Java2D :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

final PauseTransition repaintPause = new PauseTransition(Duration.seconds(1/60d)); repaintPause.setOnFinished(actionEvent -> repaint()); final SequentialTransition repaintTimer = new SequentialTransition(repaintPause); repaintTimer.setCycleCount(SequentialtTimer.INDEFINITE); repaintTimer.play();   [...]   protected void repaint() { // Vidage de la surface pour nettoyer la pile de dessin du Canvas. canvas.getGraphicsContext2D().clearRect(0, 0, width, height); // Dessin du reste. [...] }

---

Également la lib tierce et gratuite FXGraphics2D permet de faire... du Java2D sur du Canvas !!!
Donc tu peux même te permettre le luxe de faire comme a l'ancienne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

private final FXGraphics2D g2d = new FXGraphics2D(canvas.getGraphicsContext2D());   [...]   protected void repaint() { // Vidage de la surface pour nettoyer la pile de dessin du Canvas. canvas.getGraphicsContext2D().clearRect(0, 0, width, height); // Dessin du reste sur g2d en utilisant Java2D !!!!! g2d.setPaint(java.awt.Color.RED); [...] }

---

Non, pour le reste en SceneGraph.

Mais il est plus probable que tu ais code ton animation n'importe comment mais comme tu n'as pas poste ton code, difficile de savoir ce qui cloche :sm:

Merci Bouye.

Si je n'ai pas mis le code :P , c'est que mon but n'était pas de faire corriger mon code (je reviendrais peut être plus tard pour ça) mais bien pour avoir une réponse sur cet aspect théorique des animations. La réponse me convient très bien. Je vais tester pour voir ce qui conviendra le mieux.

++

Chak

Un message pour dire qu'au cours de mes recherches, je suis tombé sur un blog évoquant la classe AnimationTimer qui permet pas mal de chose finalement. En tout cas , cela m'évite le Canvas...

++

Chak!

C'est une classe de l'API de bas niveau d'animation (elle fait aussi partie du package javafx.animation tout comme Timeline) qui permet effectivement de faire des choses avec une granularité fine (ex : Using the JavaFX AnimationTimer

Ceci dit, et comme le dit l'auteur de l'article (qui est un des créateurs de l'API de propriété JavaFX), cette classe est surtout utile dans autre chose que les animations justement. Utiliser Timeline, les transition et le "tweening" rend les chose bien plus facile que devoir tout se taper à la main dans la majorité des cas. Mais dans le cas présenté ici, oui, une fontaine à particules est plus facile à implémenter avec cette classe qu'avec les autres classes d'animation.

Hum... je vais quand même aller rajouter une Q/R sur ça dans la future maj de la FAQ puisque ça semble intéresser des gens.

Citation:

---

Envoyé par bouye

C'est une classe de l'API de bas niveau d'animation (elle fait aussi partie du package javafx.animation tout comme Timeline) qui permet effectivement de faire des choses avec une granularité fine (ex : Using the JavaFX AnimationTimer

Ceci dit, et comme le dit l'auteur de l'article (qui est un des créateurs de l'API de propriété JavaFX), cette classe est surtout utile dans autre chose que les animations justement. Utiliser Timeline, les transition et le "tweening" rend les chose bien plus facile que devoir tout se taper à la main dans la majorité des cas. Mais dans le cas présenté ici, oui, une fontaine à particules est plus facile à implémenter avec cette classe qu'avec les autres classes d'animation.

Hum... je vais quand même aller rajouter une Q/R sur ça dans la future maj de la FAQ puisque ça semble intéresser des gens.

---

La granularité fine m'intéressait même si, là, en l'occurrence, ça semble limite trop fin :aie:. Sinon, un exemple de la doc officielle combine une Timeline et un AnimationTimer ce qui m'a un peu aidé également.

Marrant mais ça donne l'impression qu'AnimationTimer aurait presque du s'appeler Timeline finalement :ptdr:...

++

Chak

Moi j'aurai surtout appelé ça FineGrainTimer car de base à part le fait que ça tourne sur le thread des animations (et donc à 60Hz) ça n'a pas grand chose à voir avec les animations en elle-même.

Timeline (et donc Transition) est basé sur le tweening (j'ai lié l'article EN car l'article FR est ridiculement court). Ce qui permet de faire des animations comme en Flash : on défini la position de début et de fin d'un propriété (ou plus) et le logiciel interpole la valeur de la propriété entre les deux positions temporelles (avec la fonction/objet fourni interpolator). Ce qui permet d'avoir la position de l'objet rien qu'en spécifiant le temps de l'animation. Tout est calculé automatiquement.

Avec AnimationTimer, tu reçois juste le temps actuel et c'est à toi de te débrouiller pour savoir ce que tu dois faire à ce moment là (éventuellement en fonction de ce que tu as fais la fois d'avant). Parmis les usages non-directement graphique, on peut par exemple l'utiliser pour faire "vivre" le monde dans un jeu (déplacer les ennemis, etc.) coté serveur (on peut conceptuellement découper le jeu en une partie server et une partie affichage cliente sur un jeu tournant sur le même ordi, sans directement avoir un jeu qui ne peut se jouer qu'en réseau/sur le net avec un server/server).

Mais dans les deux cas, j'insiste bien, en JavaFX, le programmeur ne demande jamais le réaffichage de la scène (ce qu'on faisait en AWT/Swing en appelant paint() ou repaint()). Ici la scène* (ou une partie de la scène) sera ré affichée uniquement si on est emmené à manipuler la valeur d'une propriété qui doit provoquer une modification de l'affichage (c'est le principe du SceneGraph).

*En fait, l'arbre graphique que le programmeur manipule dans le SceneGraph via l'API publique n'est même pas celui qui est visible à l'écran. Il existe un second arbre graphique interne à Prism qui est une copie de celui manipulé par le programmeur. A chaque pulse du timer, Prism synchronise l'état de l'arbre du SceneGraph publique avec celui privé pour faire son affichage (source : Richard Bair, JavaFX Lead Architect, JavaOne '11 et '12).

Citation:

---

Envoyé par bouye

Moi j'aurai surtout appelé ça FineGrainTimer car de base à part le fait que ça tourne sur le thread des animations (et donc à 60Hz) ça n'a pas grand chose à voir avec les animations en elle-même.

Timeline (et donc Transition) est basé sur le tweening (j'ai lié l'article EN car l'article FR est ridiculement court). Ce qui permet de faire des animations comme en Flash : on défini la position de début et de fin d'un propriété (ou plus) et le logiciel interpole la valeur de la propriété entre les deux positions temporelles (avec la fonction/objet fourni interpolator). Ce qui permet d'avoir la position de l'objet rien qu'en spécifiant le temps de l'animation. Tout est calculé automatiquement.
...
Avec AnimationTimer, tu reçois juste le temps actuel et c'est à toi de te débrouiller pour savoir ce que tu dois faire à ce moment là (éventuellement en fonction de ce que tu as fais la fois d'avant). Parmis les usages non-directement graphique, on peut par exemple l'utiliser pour faire "vivre" le monde dans un jeu (déplacer les ennemis, etc.) coté serveur (on peut conceptuellement découper le jeu en une partie server et une partie affichage cliente sur un jeu tournant sur le même ordi, sans directement avoir un jeu qui ne peut se jouer qu'en réseau/sur le net avec un server/server).

Mais dans les deux cas, j'insiste bien, en JavaFX, le programmeur ne demande jamais le réaffichage de la scène (ce qu'on faisait en AWT/Swing en appelant paint() ou repaint()). Ici la scène* (ou une partie de la scène) sera ré affichée uniquement si on est emmené à manipuler la valeur d'une propriété qui doit provoquer une modification de l'affichage (c'est le principe du SceneGraph).

*En fait, l'arbre graphique que le programmeur manipule dans le SceneGraph via l'API publique n'est même pas celui qui est visible à l'écran. Il existe un second arbre graphique interne à Prism qui est une copie de celui manipulé par le programmeur. A chaque pulse du timer, Prism synchronise l'état de l'arbre du SceneGraph publique avec celui privé pour faire son affichage (source : Richard Bair, JavaFX Lead Architect, JavaOne '11 et '12).

---

Je bidouille depuis plusieurs jours sur le sujet et j'avoue réviser ma position sur le Timeline & Co... Pour la gestion du SceneGraph, le changement m'a un peu surpris par rapport à Swing, même si, au final, il suffit de s'accrocher pour parvenir à ce qu'on veut. J'ai certainement pêché par volonté d'aller trop vite...

L'AnimationTimer m'intéresse par contre réellement pour un autre projet où il doit y avoir un mécanisme de type "chef d'orchestre" pour lequel il conviendra parfaitement.

++

Chak