-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tagfetcher: cache fetched covers #12301
Conversation
23e8213
to
f4e046c
Compare
Rebased, I adjusted & simplified related code a bit, e.g. loading a cover to DlgCoverArtFullsize. However, (ab)using QPixmapCache is not the way to go: it's capped to 20 MB, and fetching some 1200px covers would flush all covers cached by the library table. So a QCache is unavoidable. (that simplifies clearing the flushing the fetched covers... a lot) |
f4e046c
to
cf6c689
Compare
Now the covers are cached in a QMap. I didn't set a cache limit, yet. Let's figure out a reasonable size, i.e. for how many high-res covers the size would become a problem. I couldn't get it to work with QCache, I always got segfaults when retrieving pixmaps. Must be something with QCache taking ownership of the objects and/or with QPixmap being one of the implicitly shared classes, but I couldn't figure it out. Same when I stored the fetched QByteArray, it was always nulled for some reason. If someone wants to take a look, the experimental QCache commits are in https://github.com/ronso0/mixxx/tree/tagfetcher-cache-fetched-covers_qcache. |
cf6c689
to
cd1e4e1
Compare
@@ -107,5 +111,7 @@ class DlgTagFetcher : public QDialog, public Ui::DlgTagFetcher { | |||
|
|||
QByteArray m_fetchedCoverArtByteArrays; | |||
|
|||
QMap<QString, QPixmap> m_coverCache; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider to extend use the exiting cover cache here?
I have not looked into it, but I can imagine that this way we can save one cover access.
An other option is to use QPixmapCache or the general purpose QCache container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the comments above I explained why QPixmapCache is unsuitable (e.g. it requires manual cleanup), and that I didn't get it to work with QCache. QPixmapCache is derived from QCache).
Any idea how to fix the QCache implementation is welcome, even though the only benefits seem to be slightly faster lookup and automatic cleanup (limit).
ab23b90
to
973d012
Compare
973d012
to
15fb353
Compare
It looks like this is mergable after you have rebased out the debug commit. |
Oh great, will do. |
Co-authored-by: Daniel Schürmann <[email protected]>
15fb353
to
6e5082a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks and works good! Thank you.
Closes #11084
A quick test to cache the fetched cover images with
the globala QMap.QPixmapCache
Cache keys are
"DlgTagftecher" +the MusicBrainz release id.This greatly improves UX when comparing covers of MusicBrainz results.
Works good, though removing the covers from the cache is a bit dirty I think.To discuss:* really use global QPixmapCache which is also used by CoverArtCache?* shall we increase the QPixmapCache cache limit when DlgTagFetcher is constructed to avoid clearing cached covers by adding large fetched covers?I didn't check the sizes of fetched covers, yet, we need to estimate a reasonable limit.
ToDo
currently the preference is read from config each time image urls are received. With the current implementation this may result in a mismatch of current size preference / cached images.
We could
a) read from config once in the constructor to avoid the issue in the first place
b) read the preference each time urls are received and use the size preference (int) for the cache key
based on #12300