QML ListView freezes with large models - creates and destroys all items

[A Former User]

@JoeCFD said in QML ListView freezes with large models - creates and destroys all items:

measure time to check if addition and deletion are too fast. If yes, add a timer to add them one after another smoothly.

You mean slowly add to the model rather than just setting the model? That could help, but it doesn't really answer my question

like i should be able to just set the model
model = <big array>
listviews are supposed to only load items inside the visible area

and i don't get what you mean by "measure time to check if addition and deletion are too fast. " measure what time?

[JoeCFD]

@eramne you measure the time between two additions or deletions or one addition and one deletion.
Remember that each addition or deletion will trigger update of the GUI. Cache all data into a string list and add them slowly one after another with a timer when needed. I do not know how your data is generated.

[A Former User]

@JoeCFD but what does the speed of created delegates have to do with my problem?

let me restate my problem - i'm trying to set the list's model to a large model; the list view should create only the delegates that would be inside the visible area, but instead it creates delegates for all the items in the model and deletes them after, leaving the visible area. But it should only create the delegates that are needed, and ignore ones outside the visible area, and i thought that's what list views were supposed to do. I thought this whole system of loading items in the view and destroying ones outside the view was meant to allow large models in listviews? is this a bug, can i work around it?

[JoeCFD]

@eramne I guess list view will create as many delegates as the size of your model. If you add any new to the model, a new delegate will be created. You need to know if you are replacing an item or adding an item to the model.

[A Former User]

@JoeCFD

You need to know if you are replacing an item or adding an item to the model.

i'm setting the model to a large javascript array

I guess list view will create as many delegates as the size of your model. If you add any new to the model, a new delegate will be created.

but it shouldn't, that's what i'm saying
it should only need to create what's visible
instead, it creates all of them, and destroys everything except what's visible
its a redundant middle step that's causing it to freeze
i'm asking, is this a bug with the ListView? can i work around it?

[JoeCFD]

@eramne I could be wrong. Simply try your code with large size in your model to see how many delegates are created(you have output messages). I use C++ code with Qt StringListModel as model to display debug messages and did not see any freezing issue.

[A Former User]

@JoeCFD said in QML ListView freezes with large models - creates and destroys all items:

@eramne I could be wrong. Simply try your code with large size in your model to see how many delegates are created(you have output messages).

yeah, i already did that, and said what i discovered was happening in the question and in the replies.
i logged when items are created and destroyed, and discovered that:

it should only need to create what's visible
instead, it creates all of them, and destroys everything except what's visible
its a redundant middle step that's causing it to freeze

i added an image in the first post too

[jeremy_k]

What version of Qt and platform is this occurring on?

Try printing the index, or another unique identifier from the model items to determine if it is creating and destroying for every index, or repeatedly for the same subset.

[A Former User]

@jeremy_k on Qt 6.4.0

huh..

(at the beginning)

(later)

that's bizarre, it's just creating and destroying the same items over and over again
(and when i supply it with a smaller model, it creates and destroys less and loads quicker)

Oh, i'm setting the model several times, that's why, one time for every single item
it should only be setting the model once, i'll have to go see where else it's setting it
ok i can work from here on my own

[jeremy_k]

Defining a handler for a property change signal, and then setting a break point in that handler is my usual technique for finding unwanted changes.