Version: (using KDE 4.0.4) Installed from: SuSE RPMs OS: Linux Very often Gwenview crashes. Application case: Go through a list of photos (about 2.5 MB jpegs). Edit (rotate) some of them, say 15. Gwenview now reqires about 1.5 GB RAM! After rotating 30 images without saving during this process, Gwenview crashes (computer then is totally in swap, no mouse movement even possible). It does not seem to be a memory leak, but a design issue: Does Gwenview store jpeg images as jpegs or does it expand the images to their rel size (this seems to, since the memory usage grows by about 10MB when loading a single image)? Does Gwenview store the operation ("rotate") or does it save the images during the command flow (in order to provide undo/redo functionality)??? (memory grows while rotating images)
removed this bug since I commited it twice at the same time!
Closed the right bug, opening again.
Gwenview keeps modified images in memory, that's why memory usage grows that much. It should probably store the result in temporary files when memory usage starts to be too high. Unfortunately we are in feature freeze right now, so implementing this is a bit risky. It will have to wait for KDE4.2. All I can suggest for now is to save your changes when they become too numerous.
I am afraid that using temporary files kills the performance. One issue is the disk usage, second the hdd traffic (many notebooks are weak regarding hdd capacity and speed). When considering the available modifier operations in Gwenview, I wonder if the edited steps must be saved at all. It could be wise to save the original image (and even here no high resolution image must be stored, but only the one which is displayed) and additionally the operation in terms of an 'enum'. No more storage. When the image is going to be shown, the operations will be applied at runtime to the original picture. As long as the operations consider simple resize/scaling and rotating, this should not be a performance problem at all... Off course, a comparing benchmark is required...
SVN commit 816456 by gateau: Warn the user when he made too many changes. CCBUG:162505 M +109 -63 app/savebar.cpp M +1 -0 lib/CMakeLists.txt M +8 -0 lib/document/document.cpp M +5 -0 lib/document/document.h M +6 -0 lib/gwenviewconfig.kcfg WebSVN link: http://websvn.kde.org/?view=rev&revision=816456
The patch is supposed to be a joke, right? I'm running gwenview from KDE4.1.1 on openSUSE 11.0. After rotating about 30 photos, it told me to save it. I did (took awfully long, which in fact spoiled the whole presentation), but the memory was not returned to the system. After a few more photos the system with 2GB RAM started to swap and that was it. After waiting about 10 minutes I had to reboot using Alt+SysRq+U,B. Very nice thing to do when you are showing your photos to your family. So, please consider some completely different solution (e.g. you can just record the type of the changes and filenames and apply them afterwards) or make an option to save after each change (and make it default, otherwise your application is a system killer). BTW, gwenview from KDE3.5 works smoothly and offers much more features. And as for waiting till KDE4.2, why do you consider fixing this problem a feature? It is rather a critical bug fix, I would say. Best, -- Petr
Any news on this ?
Not much, except for a fix in the memory usage detection system (bug 181235). I am still not sure whether it would be better to: - stay the way it is right now - go for the save-to-tmp way - go for the remember-changes-and-apply-on-save way
(In reply to comment #8) > Not much, except for a fix in the memory usage detection system (bug 181235). I > am still not sure whether it would be better to: > - stay the way it is right now > - go for the save-to-tmp way > - go for the remember-changes-and-apply-on-save way What about combination? Remember simple changes and apply them on save, store the whole (compresses) image for non trivial changes and use temp file when no memory.
Is this still valid for Gwenview 4.10.0 or later? I have too much RAM to test this reliably here
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!