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.