diff options
author | Samuel Rødal <samuel.rodal@nokia.com> | 2011-09-09 07:51:18 (GMT) |
---|---|---|
committer | Samuel Rødal <samuel.rodal@nokia.com> | 2011-09-09 08:19:22 (GMT) |
commit | 7ab0bed3a56d46c386e65abc381264c57137cb43 (patch) | |
tree | 1c6e26116aac3a2bc57ac26692f5262aecbf95cd /demos | |
parent | 786b85b13bc884a8b7eab59c43d6c393863fc470 (diff) | |
download | Qt-7ab0bed3a56d46c386e65abc381264c57137cb43.zip Qt-7ab0bed3a56d46c386e65abc381264c57137cb43.tar.gz Qt-7ab0bed3a56d46c386e65abc381264c57137cb43.tar.bz2 |
Prevent QPixmapCache potentially growing indefinitely.
QPixmapCache has until now refused to throw out shared pixmaps, i.e.
ones that still have shallow copies lying around. This leads to problems
when someone inserts two shallow copies using different keys, causing
the cache itself containing multiple shallow copies and thus forever
refusing to throw out those entries.
It's rather easy for this to accidentally happen in a user application
since QPixmap::load() or QPixmap(const QString &fileName, ...)
automatically cache the pixmap in the QPixmapCache, thus if the user
then calls QPixmapCache::insert() on the same pixmap or a shallow copy
it is locked in the QPixmapCache forever.
The only reason for not throwing out a pixmap that's shared would be to
prevent re-loading a pixmap from file when a user has a direct reference
to it in his application, but in that case the user is unlikely to
re-load the pixmap from file in any case. Therefore it seems the best
fix is to get rid of this limitation.
Task-number: QTBUG-21359
Reviewed-by: John Brooks
Reviewed-by: Olivier Goffart
Diffstat (limited to 'demos')
0 files changed, 0 insertions, 0 deletions