Resizing stage creates delays in platform.runLater pool?

[Guillaume Anctil]

It might be something like that. But it seems to be in the platform, not
application related.

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>
wrote:

> My guess would be that the number of resize events is swamping the event
> queue.
>
> > 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:
> >
> https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java
> >
> > This is only a tread that acquires a semaphore, prints the
> > System.nanotime() delta and releases the semaphore. There's a button on
> the
> > 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.
> Restarting
> > 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.
>