Resizing stage creates delays in platform.runLater pool?
drakkoon at gmail.com
Mon Jun 2 14:43:28 UTC 2014
It might be something like that. But it seems to be in the platform, not
When detecting a resize, I tried putting the thread to sleep for a long
amount of time. Something like 5 seconds before adding a new Runnable in
the Platform.runLater queue. It's still very slow when it starts again.
(Only when there's an animation running).
Could it be that the animation pulse + resize swamps he queue and it never
gets back to full speed again? Does the pulse have a high priority? The
fade animation on the button never seems to slow down.
On Mon, Jun 2, 2014 at 10:23 AM, Richard Bair <richard.bair at oracle.com>
> My guess would be that the number of resize events is swamping the event
> > On Jun 2, 2014, at 7:20 AM, Guillaume Anctil <drakkoon at gmail.com> wrote:
> > Hi,
> > I have encountered severe lag in my application when resizing the stage
> > while an animation is running.
> > I've made this very simple example code to reproduce the issue:
> > This is only a tread that acquires a semaphore, prints the
> > System.nanotime() delta and releases the semaphore. There's a button on
> > stage that can clicked on to start a fade animation and stop it.
> > Resizing the stage while it is animating will create huge deltas in the
> > thread. Stopping the animation brings everything back to normal.
> > the animation once resized and stopped does not create the huge deltas
> > until you resize again.
> > Does anyone know what is at play here, what underlying system creates the
> > lag and how to avoid this?
> > Thanks.
More information about the openjfx-dev