Okay :) So you are using opacityProperty() and not visibleProperty(), so my exact workaround would not work anyway. A nice thing about that kind of workaround though is that you would have the workaround in one place and once you remove it, the compiler points you to all other places you need to edit. But since the places you need to edit independently are exactly 2, it's not that bad :)
Tomas On Sat, Oct 4, 2014 at 12:16 AM, Mike Hearn <[email protected]> wrote: > Oh well the hacks aren't so bad :-) > > Hack 1: > > > animatedBind(loadingIndicatorArea, > loadingIndicatorArea.opacityProperty(), > when(isLoading).then(1.0).otherwise(0.0)); > // Hack around a bug in jfx: progress indicator leaks the spinner > animation even if it's invisible so we have > // to forcibly end the animation here to avoid burning cpu. > loadingIndicator.progressProperty().bind( > > when(loadingIndicatorArea.opacityProperty().greaterThan(0.0)).then(-1).otherwise(0) > ); > > > Hack 2: > > > if (syncItem != null) { > // Hack around JFX progress animator leak bug. > GuiUtils.runOnGuiThreadAfter(500, () -> { > syncItem.cancel(); > syncItem = null; > }); > } > > > The runOnGuiThreadAfter() call can just be removed once the bug is resolved. > No big deal. It was finding all the leaks that was the painful part, and > figuring out what combination of things would make the animations stop. > Finding the receivers array and figuring out how to trace the object graph > back to the widgets causing them was the breakthrough.
