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 <[email protected]> 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 <[email protected]> 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. >
