The indeterminate mode of ProgressBar uses 20-25% of my 2.6 GHz CPU (almost a whole core). This occurs also if the progressbar is invisible. The CPU load also depends on the width of the control and whether it is embedded in Swing or not. Above values are for a Swing application. Without Swing the load is about half of that.

Since the indeterminate mode is the default it is easy to fall into this trap, too: just add <Progressbar/> to your fxml inside an invisible container and you get high CPU load which is hard to debug. I noticed that suspending the quantum thread would stop the CPU load but that does not help much to find out exactly which control might be causing this.

I think that a fix should address two issues:
1. Less CPU load when the indeterminate progressbar is visible. It seems to run with too many frames per second...
2. No extra CPU load at all if the indeterminate progressbar is not visible. This was partially fixed with RT-11577 but that fix did not consider visibility of parent nodes in the scene graph. (Workaround for progressbar in invisible container: progress="0" or visible="false" on progressbar itself).

I have attached two example classes, an FX application and a Swing application with JFXPanel. In the Swing application things seem to be worse (uses more CPU). This is also how I noticed this because I am adding JFXPanels to a Swing application. In the examples, CPU load is reduced only if the progressbar itself is made invisible or if its width is reduced.