> -----Original Message----- > From: ext David Faure [mailto:[email protected]] > On Monday 23 July 2012 23:58:16 [email protected] 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
