Discussion :

[r1-1024]

Bonjour à tous,
J'aimerai utiliser javafx sans être dans l'EDT (juste utiliser le langage fx dans une autre api graphique).

La seule façon de le faire pour moi est de définir des classes java qui font le coeur de l'API puis étendre ces classes en fx pour avoir une syntaxe purement fx.

Le pb c'est que de base on est dans l'EDT.

java :

Code :

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

1
2
3
4
5
6
7
8
 
public class ThreadDisplayer 
{
	public void whoAmI()
	{
		System.out.println("You are : "+Thread.currentThread().getName());
	}
}

javafx :

Code :

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

1
2
3
4
5
6
7
 
var displayer:ThreadDisplayer=new ThreadDisplayer();
 
public function run(args:String[])
{
	displayer.whoAmI();
}

Et le résultat :

You are : AWT-EventQueue-0

Alors y a t il un moyen d'être dans un autre thread ?

[r1-1024]

Pour ceux que ça intéresse voilà un lien sur le bind java/javafx
http://blogs.sun.com/michaelheinrich...ects_in_javafx

C lourd tout ça.

[r1-1024]

Et voilà un petit exemple de bind java->javafx (bcp plus simple que javafx <-> java)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
import javax.swing.JFrame;
 
public class FXJFrame
{
	 protected var f:JFrame=new JFrame();
 
	 public-init var title:String on replace
	 {
	 	f.setTitle(title);
	 }
 
	 public-init var size:Integer[] on replace
	 {
	     if(sizeof(size)!=2)
	     	throw new java.lang.IllegalArgumentException();
	     f.setSize(size[0],size[1]);
	 }
 
	 public-init var visible:Boolean on replace
	 {
	 	 f.setVisible(visible);
	 }
}
 
public function run(args:String[])
{
  var frame:FXJFrame=FXJFrame
  {
      title:"Hello Binders"
      size:[100,100]
      visible:true
  };
 
  frame.size=[500,500];
}

Comme on peut le voir il y a forcément copie des données côté javafx.
En concevant une API javafx/java il est surement impératif de séparer les données du traitement.

Ici ça serait un truc du genre :
Côté java :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public interface JFrameDataProvider
{
   String getTitle();
   setTitle(String title);
   ...
}
 
public class JFrame
{
   private JFrameDataProvider data;
 
   public JFrame (JFrameDataProvider data)
   {
     this.data=data;
   }
 
}

côté javafx

Code :

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

1
2
3
4
5
6
7
8
 
public class FXJFrame extends JFrameDataProvider
{
   protected var f:JFrame=new JFrame(this);
 
   //ici on ajoute les champs title, size ....
 
}

Comme ça on a pas de duplication de données
Évidement c'est un éxemple (on va pas reprogramer JFrame, de toute façon on peut pas).

Qu'en pensez vous ?
Ya des idées pour tourner en dehors de l'EDT ?

[PhiLho]

utiliser le langage fx dans une autre api graphique

Quelle drôle d'idée !
Ça serait peut-être plus simple de refaire un DSL... Voire de faire une description de données en Json ou Yaml.
Ou si tu es courageux (et avec pas mal de temps libre...), tu prends le compilateur JavaFX (la seule partie open source...) et tu l'adaptes à tes besoins...

Mais bon, en gros, je crains (sans être une autorité sur le sujet !) que ce ne soit pas possible, j'ai vu à plusieurs reprise que JavaFX est purement monothread.
D'ailleurs, si on veut utiliser Async, si je ne m'abuse, le code tournant dans l'autre thread doit être du code Java, on ne peut pas utiliser JavaFX là...

[r1-1024]

Moteur 3D jogl performant. Je ne pense vraiment pas qu'on aura un truc comme ça de base en fx avant pas mal de temps. Sun est surement confronté au même dilemne qu'Adobe sur le sujet.

Fin le bind est facile! Un coup d'introspection sur les interfaces et le reste peut être auto généré. A part qq classes.

Le pb reste que forcer la synchro EDT réduit les perfs en multi vue....

Si j'ai répondu à ta question

[r1-1024]

Pour ceux qui en doutaient encore (y compris moi même), voilà un petit shot de la vue fx comme je le disais plus haut.

C'est le petit lapin des démos jogl dans le moteur 3D dont je parlais (mais ça prouve que ça fonctionne).
Le portage n'est pas loin



Sans même modifier le classpath !
Et là bcp de surprises (mais pas tant que ça)

En animant le lapin :
-Si on utilise un GLCanvas : consomation CPU 3%
-Si on utilise un GLJPanel : consomation CPU 50% (j'suis en dual core)

C'est la conf du viewer qui permet ça (GLCanvas ou GLJPanel).
Vu la consommation CPU de javafx (d'un Stage), et le peu d'intérêt d'un GLJPanel (à part de rester en composant léger) il semble qu'ils utilisent un GLJPanel & co.

Mais avec une vrai accélération 3D (GLCanvas), impossible de le visualiser en applet (c'est un peu normal car j'utilise pas de Stage).
Si le runtime en cache est le même que celui du dev kit ya pas de raison de ne pas pouvoir avoir une vrai 3D dans un browser.

Voilà mon code source pour ceux qui auraient une proposition pour l'applet :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
public function run(args:String[])
{
   var frame:JFrame=new JFrame();
   //create the behavior
   var be:DSBehavior=new DSBehavior();
   //the renderer
   var bck:GradBackGround=new GradBackGround(new GLColorRGB(new Color(3,3,64)),
    				new GLColorRGB(new Color(240,240,240)));
   var re:DrawerRenderer=new DrawerRenderer(bck,null);
 
   addDrawers(re);
 
   //add the samples listeners
   SamplesHandler.getDefault().add(new StdOutSamplesListener());
 
      //var viewer:View=new View(new AbstractViewportHandler(be,re),false,true,false);
   var viewer:View=new View(new AbstractViewportHandler(be,re),true,false,false);
   frame.getContentPane().add(viewer);
   frame.setSize(900,900);
   frame.setVisible(true);
}
 
function addDrawers(re:DrawerRenderer)
{
   try 
   {
   var bunny:Bunny=new Bunny();
 
   re.add(new WireFrame(bunny));
   } 
   catch (e:IOException) 
   {
   e.printStackTrace();
   }
}

La décompilation fx runtime n'est pas loin (ou alors faut attendre les src de Sun).

Et vive Java !