[Development] QML pixmap caching

[martin.jones at nokia.com]

> -----Original Message-----
> From: ext David Faure [mailto:david.faure at kdab.com]
> On Monday 23 July 2012 23:58:16 martin.jones at nokia.com wrote:
> > > So maybe this should be configurable?
> >
> > Perhaps.  I'm wary of exposing details of the current implementation in
> API.
> 
> I'm not sure how this is an implementation detail. It can be as high level as
> "cache size in MB".
> QPixmapCache has that. ListView has "bufferSize" for something similar
> (but PathView is missing it, which is what's creating this problem in the first
> place). Overall, I think giving tools to tune the RAM vs CPU tradeoff is
> important, especially with a focus on animations and embedded...
> (therefore both CPU and RAM can be important limitations, depending on
> the actual use cases).

I have no issue with setting cache size.  I'm not so keen on deeper configuration options.

> > > Or is the only option to create my own QDeclarativeImageProvider
> > > which keeps everything in memory?
> >
> > This is the only option at the moment.
> 
> So, I've done that, and discovered another small issue: since I do my own
> caching in the provider, I want to bypass the internal caching, which I do
> with "cache: false" in the image elements. However when the images are
> unref'ed, they still count as part of the m_unreferencedCost, which triggers
> "cache shrinking".
> Shouldn't this be skipped for non-cached images?
> 
[snip patch]
> 
> This works great here, but I'm wondering if un-cached pixmaps should go
> into m_lastUnreferencedPixmap and m_unreferencedPixmaps. Maybe the
> above patch makes that list grow forever, if all images are uncached?

I don't think they should go into the unreferenced list at all.  I'll look into it.

> > > I'll do that for now, but it seems like there should be an easier
> > > way to tell QML "keep stuff in cache as long as the cache isn't too
> > > big" (and the cache size could possibly be made configurable, too,
> > > like in QPixmapCache).
> > I agree that the current strategy is too aggressively discarding
> > images.  The simplest solution I can think of is to have a lower and
> > upper bound, so that the cache allows up to say 25% of its capacity to
> > remain indefinitely.
> 
> That would work ok in some cases and it would already be an improvement
> IMHO, but of course one might want to tune this number too...

Yes, you might, but this is one of those implementation details I'm not keen on exposing.

> > It should be possible to set the cache size too.  This is a task that
> > has been around for some time
> > https://bugreports.qt-project.org/browse/QTBUG-19507
> 
> Could you advise the guy in that report, about which API would be good for
> this?
> Then he can finish the patch and contribute it...

We'll find a place for the API and make a patch, write tests, etc.  At the moment I favor static void QQuickWindow::setImageCacheLimit(int)

Br,
Martin.