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

Kevin Rushforth kevin.rushforth at
Fri Oct 3 22:06:25 UTC 2014

Can you add this workaround to the JIRA?


-- Kevin

Tomas Mikula wrote:
> 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> 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:
>> 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