Created attachment 68094 [details] Test program showing QProgressBar. Version: 4.0 (using KDE 4.7.3) OS: Linux I have attached a simple test program that shows just a progress bar filling over and over. When run this program will consume a lot of memory. The ammount of memory used seems to depend on the width of the progress bar and the number of steps taken. It does not look like a memory leak as the memory usage stops climbing after a while. Still a program using 50+ MB of memory showing just a progres bar seems a bit execive. (for this amount the bar should be extended to cover the whole screen) This memory usage is not seen when other styles are used. Hence a bug report against Oxygen. Reproducible: Always Steps to Reproduce: Run the test program. Actual Results: Many memories taken. Expected Results: Not so many memories taken. Obvously using the very fine Oxygen style. On a 64bit Kubuntu 11.10 install
No leak indeed. This is a cache that gets filled with the scrollbars pixmaps. These are CPU intensive to compute, hence the cache. Indeed there is one different pixmap per item. So you end up with a lot of pixmaps, for a long progressbar that gets filled by units of 1. I tend to see this as a corner case though. No ? I guess I could reduce the size of the cache. though this would result in less memory but more slugishness (and I can bet there will be another bug report about it). The other possibility would be to change the way the rendering is done, to "stretch" rather than cache, the center part of the progressbar. But here also, expect some sluggishness and CPU. So ... what do you think ?
Thanks for the quick response. My guess would be that the computations aren't that much of a problem. As you can see with the test program, the initial fill does not take that much time on the CPU. Actually I can't spot any difference to the second time. Maybe the GPU helps? Secondly my guess is that a lot of uses for the progress bar would discard the bar after one operation so the cache becomes useless there. Would it be feasible to share the cache between applications in a similar way to Q/KIcon. That would make a cache properly useful. Otherwise I would opt to not use it. Maybe it is possible to do caching of a few key fill ratios and stretch those. There might be a middle ground that is optimal for both repeat and single uses of a progress bar. I'm not sure how the style is computed, but just to put my mind at ease: It would be best to not really look at the actual QProgressBar.value() because the min/max can change between runs. Some background on my use: It is used as a progress indicator in a MPD client. The max is set to the length of the song and than every second the value is incremented. This results in 1/3th of the total memory footprint being progress bar pixmaps.
See also http://commits.kde.org/muon/478274d
Git commit 04490c8a827347ed41b9b1bee0539cea750ddf50 by Hugo Pereira Da Costa. Committed on 14/02/2012 at 19:06. Pushed by hpereiradacosta into branch 'master'. add 'stretch' flag, to stretch, instead of tile, the sides and center pixmaps. M +63 -17 libs/oxygen/oxygentileset.cpp M +5 -2 libs/oxygen/oxygentileset.h http://commits.kde.org/kde-workspace/04490c8a827347ed41b9b1bee0539cea750ddf50
Git commit ab8b72b6c400800dd31376b73ea4cc2668b3609b by Hugo Pereira Da Costa. Committed on 14/02/2012 at 19:06. Pushed by hpereiradacosta into branch 'KDE/4.8'. add 'stretch' flag, to stretch, instead of tile, the sides and center pixmaps. M +63 -17 libs/oxygen/oxygentileset.cpp M +5 -2 libs/oxygen/oxygentileset.h http://commits.kde.org/kde-workspace/ab8b72b6c400800dd31376b73ea4cc2668b3609b
Git commit 351110c99de602b6e99ba4df4c917b4e6928d672 by Hugo Pereira Da Costa. Committed on 14/02/2012 at 20:50. Pushed by hpereiradacosta into branch 'KDE/4.8'. Use TileSets to cache progressbar indicators. Use only the small dimension of the bar in the cache. Stretch the large dimension when bar is expended. M +6 -2 kstyles/oxygen/oxygenstyle.cpp M +13 -13 kstyles/oxygen/oxygenstylehelper.cpp M +2 -4 kstyles/oxygen/oxygenstylehelper.h http://commits.kde.org/kde-workspace/351110c99de602b6e99ba4df4c917b4e6928d672
That fixes it. Also backported to KDE/4.8 (now I just need to do the same for oxygen-gtk). Closing. Thanks for reporting !
Thanks for fixing. :)