Can you add this workaround to the JIRA? Thanks.
-- 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 <[email protected]> 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.
