Update JavaFX in JFXPanel while EDT is blocked
lehmann at media-interactive.de
Mon Jun 18 06:04:01 PDT 2012
I was kinda hoping that the JFXPanel could repaint itself without
depending on the EDT - but Richard already cleared that up. As to the
steps below: I have implemented no 2 already but got big delays in
updating the progressbar (on the JFXPanel), and also animations were
stuttering or invisible (jumping to the last keyframe in one step).
Actually, those initalizations are interspersed with lots of Swing code.
It will take a while to divvy that up. Even more, this used to be done
in a background thread and did not fail, at least there were no
noticable problems. I am not trying to defend that style though. Wasn't
On 18.06.2012 14:49, Artem Ananiev wrote:
> Hi, Werner,
> your scenario doesn't look JFXPanel specific: you block EDT and at the
> same time request Swing to repaint. As expected, it doesn't work, as
> Swing repaints on EDT :) paintImmediately() may sometimes help, but be
> very careful: if you call Platform.runLatter() to update FX progress bar
> and then right after that call JFXPanel.paintImmediately(), you will
> likely get the old state of the progress bar.
> Ideally, you should move all the initialization code to background
> thread(s). When you need to update UI, e.g. update progress bar value,
> you need:
> 1. In pure Swing app: call invokeLater() and set JProgressBar's value
> from the Runnable. JProgressBar will then implicitly call repaint().
> Some time later the progress bar will be painted by RepaintManager.
> 2. in FX/Swing app: call runLater() and set ProgressBar's value from the
> Runnable. ProgressBar will then invalidate FX scene, which will trigger
> FX repaint, which will automatically call JFXPanel.repaint().
More information about the openjfx-dev