Poor ListView performance on Gluon

Question

I have a custom ListCell implementation, shown in the picture below.

The left side, which represents the date, consisting of 3 labels, put in

Answer 1

There are many reasons why the performance of a complex scene is reduced, so this is just a list of possible ideas that might help improving it, in any order.

ListCell

For starters, the number of nodes in the cell is really high. Notice that every single scroll you make means the full rendering of the virtual flow that holds the visible cells. And for every cell, that means recreating its content all over again.

Without viewing your code I can't tell, but you should avoid creating new instances of every node in the cell all the time, by having just one single instance, and in the updateItem method only change the content of the nodes.

Have a look at this sample. The NoteCell class is a custom cell, where a ListTile is used.

Number of nodes

Have you tried using just a Label to replace the 8 textfields and 3 boxes?

Cache

If you use images downloaded from Internet, use Gluon Charm Down Cache to avoid the same image being downloaded over and over again.

Have a look at this sample. Without the cache, even on desktop the performance is really affected.

Also use the JavaFX built-in cache for any node, trying different cache strategies.

CSS

Complex CSS requires long CPU time. Try to simplify it. Even you can remove the whole CSS for a quick test. Then decide what you may or may not use.

The same goes for animations: Avoid animations, transitions or even CSS effects, if possible.

Custom Control

The counter complex node could probably be replaced by a custom control that optimizes the rendering.

CharmListView

Have you tried using the Gluon Charm CharmListView control instead of the ListView?

There's a new experimental flag that you can use to test a possible optimization that might improve performance while scrolling the list. Set gluon.experimental.performance=true on the java.custom.properties file, and give it a try.

JavaFXPorts version

You mentioned you are using 8.60.6 because of the TextField bug. In this case, are your TextField nodes editable? If not, I'd suggest replacing them with other nodes and running with 8.60.7, since it contains a lot of performance improvements.

Performance tools

Use performance tools like Monitor and use its profiling options so you can trace down any possible bottle neck.

CPU

Last but not least: your mobile device specs are always critical.

Trying to render a complex scene on a Cortex A5, given that "it is the smallest, lowest cost and lowest power ARMv7 application processor", or using a very old Android 4.1.1, can't perform as well as running it on a brand new device with higher specs.

As you also mentioned, running on a Cortex A7 performs "way better". Have a look at this comparison, and find the right architecture for the job.

Anyway, there's always room for improvement, and a lot of effort is put into it. Your feedback is always welcome.