Resizing stage creates delays in platform.runLater pool?
Stephen F Northover
steve.x.northover at oracle.com
Mon Jun 2 15:06:04 UTC 2014
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.petrov at 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?
More information about the openjfx-dev