Bisq: CPU consumption skyrockets on create offer / take offer

[oscarguindzberg]

Description

CPU consumption skyrockets on create offer / take offer.

Version

1.4.0

Steps to reproduce

Option 1: Create offer

• Click "Create new offer to buy btc"
• Trading account: ETH...
• Enter any values
• Click next step

Option 2:Take offer

• Find an offer to sell btc (buy eth)
• Take the offer
• Click next

Expected behaviour

CPU consumption at normal level.

Actual behaviour

CPU consumption skyrockets. Computer performance is degraded. Java process uses 70% of the CPU.
Once I exit that screen, CPU consumption goes back to normal.

Screenshots

Device or machine

Mac OSX Catalina

Additional info

Tested on regtest connected to a localhost bitcoin core
Just to be clear, the problem is on the screen that has the "Transfer funds from bisq wallet" and "open your external wallet for funding" buttons.

[jmacxx]

Same thing happens on Ubuntu. Also, it happens on v1.3.7 mainnet as well.

Before that screen, all CPU @ 5%. On the screen mentioned, one CPU goes up to 50% and the others all go up to around 20% (from previous values @ 5%). Cancel out from that screen and they all drop down to 5% again. (Using htop to measure).

I wonder if it is the animated icon... :thinking:
.. and yes that's it. Comment out 3 occurrences of waitingForFundsSpinner.play() in MutableOfferView.java and then the CPU stays at 5%.

[wiz]

Sounds like GPU is not being used to render that animation

[chimp1984]

The spinner always had a performance issue. So that might be the reason. I think we moved to diff. buys animations elsewhere. @ripcurlx can you comment? I am not so much up to date with UI.
Another reason could be fee estimation, but a breakpoint there should easily reveal if thats the case.

[chimp1984]

Best to test to just deactivate the waitingForFundsSpinner and see if that solves it.

[wiz]

@chimp1984 yes, @jmacxx confirmed it was the spinner in his comment:

Comment out 3 occurrences of waitingForFundsSpinner.play() in MutableOfferView.java and then the CPU stays at 5%.

[chimp1984]

Ah sorry was not reading well ;-).

We created our own TxConfidenceIndicator for the same reason. BusyAnimation extends JFXSpinner. And JFXSpinner extends ProgressIndicator. ProgressIndicator is known to be terrible with CPU waste. Earlier it was BusyAnimation extends ImageView. I guess we need to kick out those ProgressIndicator implementations.

[chimp1984]

Was a very issue and was kind of resolved but seems it got re-introduced with the redesign:
https://github.com/bisq-network/bisq/issues/485

[cd2357]

Might be improved by setting https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty on these spinner and progress indicators.

(For reference, see _Did we try turning cache to true and cache hint to SPEED?_ in https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks. They're optimizing animated nodes in a simple JavaFX game, but same principles probably apply here too)

[jmacxx]

@cd2357 I added setCache(true) and setCacheHint(CacheHint.SPEED) to various places in class BusyAnimation (the constructors & the play method) but no change in behavior. CPU 2 always goes over 60% and stays there as long as the animation is shown.

Spinner being played:

No spinner: