Thank you very much Shawn! I will certainly try it out. my problem is that application needs to run on a striped Linux OS with a lot of memory, where it is the only app running so it is not really matter if it is taking too much memory. But it will also run on some old Windows systems where the memory is limited and it is taking up more than half of it.
Regards, Khuram Ali -----Original Message----- From: Shawn Rutledge <shawn.rutle...@qt.io> To: Khuram Ali <khuram....@aim.com> Cc: development <development@qt-project.org> Sent: Thu, Aug 9, 2018 3:32 pm Subject: Re: [Development] QML AnimatedImage Memory usage - QTBUG-64272 > On 3 Aug 2018, at 17:22, Khuram Ali via Development > <development@qt-project.org> wrote: > > Hi, > > I am suffering from the already reported bug > https://bugreports.qt.io/browse/QTBUG-64272. I am adding a gif and the memory > usage sky rocket to more than a GB. I have seen the bug is still open. is > there any suggested workaround to this issue? > I am using Qt 5.11.1. Thank you for your help! Well there is a patch, you could try it out and measure how much it helps in your case. https://codereview.qt-project.org/#/c/218460/ In an ideal world I think we should not consume any more memory than a couple of frames’ worth, CPU cycles being cheaper than memory nowadays. Why not decode frames on the fly? Worst case, you wouldn’t even have to load the whole gif into memory, just keep reading it from disk over and over (or maybe mmap it if that helps), and let the kernel cache take care of making that faster. Nowadays instead of “disk” we could as well call it “non-volatile memory that’s somewhat slower than RAM”. But I suppose there’s a boundary where a really big animated gif is going to be a pig no matter what, and maybe it does take too much CPU to keep decoding frames, so you need caching after all. Or, for small animations it might be worthwhile to upload all the frames to GPU memory (even put them together into an atlas if possible) to eliminate all disk-reading and most of the GPU bandwidth during steady-state run conditions. So (again in an ideal world) maybe we could auto-detect where to draw the line, do a sort of hot-spot optimization where we detect that one way takes too big a percentage of total memory, or the other way is not keeping up with the frame rate, or taking too big a percentage of CPU cycles. (Or is that hopeless because it’s too much magic, and we’d be sure to get it wrong in some cases?) (I keep wondering why there is still so little emphasis on portable software dynamically taking system resources into account and choosing appropriate optimizations automatically. We don’t seem to be doing much of that in Qt, and we aren’t doing much to help the users do it either.) But I guess we have too many layers of code involved to make any of that easy. The "two layers of caches” comment in that patch is enough to make me want to have a try at starting over; but I haven’t tried, and I figure nobody will approve a patch to do that anyway. Maybe it’s an opportunity for a third-party QtQuick Item that directly uses libgif to get just that kind of animation done as straightforwardly as possible, without supporting other types of movies. Yeah, taking hundreds of megs for smallish gifs is crazy. But so far the only patches I’ve seen are for small non-invasive optimizations.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
