Who takes care of deleting QImage returned from QQuickImageProvider?

[philk]

I can see a steady increase in memory for images loaded via my own QQuickImageProvider for gridview items. At what point are those images deleted by Qt (Quick)?

[chrisadams]

Pixmaps are cached in the QQuickPixmapStore. See https://qt.gitorious.org/qt/qtdeclarative/blobs/stable/src/quick/util/qquickpixmapcache.cpp for more details. You can manually purge the cache by calling QQuickWindow::releaseResources().

Currently, the cache_limit (size of cached pixmaps in the cache) is hardcoded into qquickpixmapcache.cpp. It probably would be useful if this was exposed via a function like QQuickWindow::setResourceCacheLimits(enum WhichResource, int limit) or something. Feel free to file a bug report about that, I guess.

Cheers,
Chris.

[philk]

Thanks Chris for your answer. However, I do not use Pixmaps, but QImage, as I wrote. What's the difference between PixMap and QImage anyway? Which uses less memory and is more efficient to render?

[chrisadams]

It's a cache of QQuickPixmap rather than QPixmap. I should have been clearer. Probably best to read the code I linked at gitorious. To create a texture from a QPixmap, it is first converted to a QImage. The rest of the code is basically identical, and it's cached the same way (what is cached is QQuickPixmapData which consists of a texture factory for the image data). In short, two requests for the same QQuickPixmap (ie, see QQuickImage for an example) won't need to go through the provider->requestImage() or provider->requestPixmap() codepath; instead, the data will be returned directly from the cache.

Performance should be mostly identical, I guess. Benchmark it to find out for yourself though, as I may be wrong about that. Certainly pixmap.toImage() must have some overhead.

What is eventually rendered is a texture, not a pixmap or an image, of course.

Cheers,
Chris.