JDK-8088857 : Menu slow to respond after resizing a window multiple times with animation running
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-08
  • Updated: 2020-01-31
  • Resolved: 2016-12-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u152Fixed 9Fixed
Related Reports
Duplicate :  
Run this sample program : 


import javafx.animation.TranslateTransition;
import javafx.application.Application;
import static javafx.application.Application.launch;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.control.Menu;
import javafx.scene.control.MenuBar;
import javafx.scene.control.MenuItem;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;
import javafx.util.Duration;

public class testTranslate extends Application {

    public void start(Stage primaryStage) {
        MenuBar bar  =new MenuBar();

        for(int i =0;i<5; ++i){
            Menu menu = new Menu("test");
            for(int j =0;j<5; ++j){
                MenuItem item = new MenuItem("test");
        Label label = new Label("this is a test");
        TranslateTransition transition = new TranslateTransition(Duration.seconds(2), label);

        BorderPane pane = new BorderPane(label);

        primaryStage.setTitle("Hello World!");
        primaryStage.setScene(new Scene(pane));

     * @param args the command line arguments
    public static void main(String[] args) {


Click on one Menu, it appears immediately. Move your mouse on the other Menu, they all appear immediately.

Now, resize the height of the window by grabbing the bottom. Resize the window by shrinking its height and enlarging it slowly like a user would. Repeat 5-6 times. 

Now try to open a Menu again, it is VERY slow to open. Why? 
What is the work-around for that?
I think this has baked in 9 long enough. Approved to backport to 8u-dev for 8u152.


It's probably OK to backport, but let's let it bake for a week in 9-dev first. That will give time to test it further.

Looks good. +1

The patch applies cleanly to 8u-dev and solves the problem(s both this and JDK-8170459) there as well. Requesting backport.

Kevin and I finally got to the bottom of this after it was reported again as JDK-8170459 and found a fix: http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.rt.00/ This should be reproducible in any build after we turned on live resizing as it is the live resize code that was accidentally resetting an important boolean flag that allowed pulse events to stack up in the queue. The same fix should apply to 8u-dev other than a change in the location of the source file.

Retargeted to tbd_major as not a regression in 8u/9 and introduced in 8 GA or earlier. However might be fixed in 9 in positive case on time resources

The symptoms above sound like perhaps a listener is added once per resize event and then we spend a lot of time delivering events to old listeners. In any case, we need to see if it is still reproducible (I'm working off my Mac partition right now so I can't test on Windows, but I'll mark this as In Progress so we are sure to get to it soon...)

It reproduces on Windows 8 just fine. Oddly, with every resize event the delay in menu response increases seemingly linearly. Resize it just a little and there is a short delay that doesn't go away - as if the menus appearing are permanently a fraction of a second behind. Resize it more just a little and the delay gets longer, but stays at that longer time. Keep resizing and every time it gets a bit longer and stays at that same delay. The amount it gets longer is proportional to how much resizing you did. As an experiment I tried pressing, resizing just a tiny amount, then holding there for a minute, then resizing just a tiny amount more, then releasing. The delay in the menus was similar to what I would have seen if I had just done that resizing quickly without the delay so it appears to be proportional to the number of resize events rather than the time used.

I tried it on Mac and it didn't seem to have any trouble. I'll double check on Windows 8 just in case it might be something about my hardware that doesn't show it.

Allright, thank you. I will try to pause and resume the animation when resizing then.

Another piece to the puzzle: it may be related to live resize, since if I disable live resize the problem never occurs. Note that without live resize, you will see significant jittering when you resize the window. To test this: java -Djavafx.live.resize=false ... But disabling and re-enabling animation might be the better workaround.

I took a quick look, and it seems that pausing and restarting the animation after the resizing it makes the performance go back to normal. Perhaps this could form the basis of a workaround for you. This also suggests that it might be an animation bug rather than a graphics bug, but it's hard to say without an analysis.

I would highly appreciate if a work-around can be found for that. I will maybe try to dive in the code in order to understand why these menus are long to open..

I can reproduce the bug. It happens in all releases of FX 8 that I tried so it is not a regression. Targeting it for 9.