Saving memory by freeing off-screen QListView items?
-
wrote on 12 Feb 2020, 04:59 last edited byThis post is deleted!
-
There is nothing like a QListView item. It's all in the model.
Don't save the images in memory in full resolution but scale them down. -
There is nothing like a QListView item. It's all in the model.
Don't save the images in memory in full resolution but scale them down.wrote on 12 Feb 2020, 05:32 last edited by@Christian-Ehrlicher I'm keeping everything heavily scaled down, actually. I guess then it becomes a matter of making my QSqlTableModel free old records.
-
@tague said in Saving memory by freeing off-screen QListView items?:
I guess then it becomes a matter of making my QSqlTableModel free old records.
How much rows do you have? QSqlTableModel can't 'free' any data.
Do you derive from QSqlTableModel and fetch the image by your own so you can scale it down? Otherwise there will be the big image in memory. -
@tague said in Saving memory by freeing off-screen QListView items?:
I guess then it becomes a matter of making my QSqlTableModel free old records.
How much rows do you have? QSqlTableModel can't 'free' any data.
Do you derive from QSqlTableModel and fetch the image by your own so you can scale it down? Otherwise there will be the big image in memory.wrote on 12 Feb 2020, 06:10 last edited by@Christian-Ehrlicher said in Saving memory by freeing off-screen QListView items?:
How much rows do you have? QSqlTableModel can't 'free' any data.
Do you derive from QSqlTableModel and fetch the image by your own so you can scale it down? Otherwise there will be the big image in memory.I don't do that at the moment, but I am working on creating a similar model class that doesn't retain row information, but instead only
SELECTs it whendatais invoked. -
Hi,
Beware with that,
datais called frequently as the model provides lots of information. Beside what @Christian-Ehrlicher already suggested, you might also want to use a windowing mechanism that fetches a fixed amount of row data and then add/remove new rows depending on the scrolling of the view. -
Hi,
Beware with that,
datais called frequently as the model provides lots of information. Beside what @Christian-Ehrlicher already suggested, you might also want to use a windowing mechanism that fetches a fixed amount of row data and then add/remove new rows depending on the scrolling of the view.wrote on 12 Feb 2020, 17:53 last edited by@SGaist Thanks for the heads up. Is there a way to do that without my model being heavily dependent on my particular QListView? So far, I've made a generic
CachingTableModelthat uses aQCacheto keep the last few hundred items cached, and which has an overridable virtual method that converts a table row into the appropriate QVariant data representation. It's actually been rather efficient (about 100MB of memory used at its peak) and on my device (with an SSD, reading from an SQLite table of around 8,000 entries) reads new entries with no trouble at all. -
Again - what do you save in that model when there are only 'a few hundreds items' in there and you need 100MB?
-
Again - what do you save in that model when there are only 'a few hundreds items' in there and you need 100MB?
wrote on 12 Feb 2020, 22:10 last edited by@Christian-Ehrlicher It caches entries that could have fairly high resolution images in them. 100MB consumed is quite reasonable for my particular use case. I've solved my problem my creating a general-purpose list model class which does not retain too many recent items in memory, and then implementing an application-specific subclass that will automatically produce small, low-resolution thumbnails and save them to a separate table to allow for faster loading later on.
-
@tague said in Saving memory by freeing off-screen QListView items?:
I guess then it becomes a matter of making my QSqlTableModel free old records.
How much rows do you have? QSqlTableModel can't 'free' any data.
Do you derive from QSqlTableModel and fetch the image by your own so you can scale it down? Otherwise there will be the big image in memory.wrote on 22 Jun 2020, 13:24 last edited byThis post is deleted!