I suggest you add yourself to the bug. At this time, we are not sure what is causing it. It could be graphics or event queue related as there is evidence that changing either solves the problem.


On 2014-06-02, 10:51 AM, Guillaume Anctil wrote:
Yes. -Dprism.order=sw does fix the issue. Looking at that bug's sample code
and how to reproduce, it looks very similar.

Thank you. I'll run it in software mode for now and see how bad it affects
performance. I can always apply a hacky workaround of stopping animations
when I detect a resize and restarting them once the resize is done.

So I guess this is on your radar, and it is being looked into?

On Mon, Jun 2, 2014 at 10:43 AM, Anthony Petrov <anthony.pet...@oracle.com>

You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796

Please try running with -Dprism.order=sw and see if this changes anything.

best regards,

On 6/2/2014 6:20 PM, Guillaume Anctil wrote:


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?


Reply via email to