How do I find out why the render loop is running?

Tomas Mikula tomas.mikula at gmail.com
Fri Oct 3 22:01:38 UTC 2014


This is just a tip: until the bug is fixed, you can use a subclass of
ProgressBar like the one below to avoid "a bunch of hacks".

class MyProgressBar extends ProgressBar {
    private final DoubleProperty myProgress = new SimpleDoubleProperty();
    public DoubleProperty myProgressProperty() { return myProgress; }
    public void setMyProgress(double progress) { myProgress.set(progress); }

    public MyProgressBar() {
        progressProperty().bind(

Bindings.when(Bindings.isNotNull(sceneProperty()).and(visibleProperty()))
                        .then(myProgress)
                        .otherwise(0);
        );
    }
}

You will have to change setProgress() and progressProperty() in your
code to setMyProgress() and myProgressProperty(). The good thing is
that if you forget to replace setProgress() by setMyProgress(), you
will get an error, because progressProperty() is now bound, so you
cannot set() it.

Hope this gets your code clarity close to the original level.

Note, however, that this will not work if a parent is made invisible.
You would need some more logic for that, unless there is an easy way
to determine whether a node is actually visible. Here is one approach
using EasyBind:

public static Binding<Boolean> nodeVisible(Node node) {
    Binding<Boolean> parentVisible = EasyBind.monadic(node.parentProperty())
            .flatMap(parent -> nodeVisible(parent))
            .orElse(true);
    return EasyBind.combine(parentVisible, node.visibleProperty(), (a,
b) -> a && b);
}

Best,
Tomas

On Fri, Oct 3, 2014 at 10:37 PM, Mike Hearn <mike at plan99.net> wrote:
> Well, this was a pain in the ass. The cause is indeed
> ProgressBar/ProgressIndicator. It turns out that they can "leak" animations
> even when removed from the scene graph or their parents are made invisible.
> I filed:
>
> https://javafx-jira.kenai.com/browse/RT-38894
>
> I now have a bunch of hacks to set the progress bar/indicators I have to
> non-indeterminate when they're no longer visible or just before they are
> removed from the scene graph, to let them clean up. I don't know why this
> is required because I can see the code is trying to do the right thing, but
> for whatever reason it does not seem to work reliably.
>
> I figured out what's running by taking a look at
> Toolkit.getToolkit().getMasterTimer().receivers every so often. A healthy
> (idling) app that isn't using up battery should have just a single entry
> inside a button click handler. If there are more, it means the app is
> animating even if nothing on the screen is changing.


More information about the openjfx-dev mailing list