https://bugs.kde.org/show_bug.cgi?id=506760
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |NEEDSINFO CC| |[email protected] Resolution|--- |WAITINGFORINFO --- Comment #1 from [email protected] --- Hello! Thank you for the bug report. Saving data successfully is important, however there's some things about your report that indicate this is more of a feature request, and not a bug. Please note that the Importance level should be set to Critical in the case of a bug that causes data loss, and set to Wish for feature requests. In trying to reproduce the issue, I created a new file at "30k x 20k" resolution (30000 x 20000), at 300dpi, in RGB/Alpha, 8-bit integer/channel depth, with sRGB built-in profile. This results in a very big file, with a single paint layer estimating at over 2GiB of RAM! If this is the resolution you are working at, this may be cause for "frozen" saves occurring often. A project at this size with a single layer containing just scribbled lines over the canvas took me roughly 25 seconds to save, where most of the time the save appeared to freeze or hang (though the program itself did not freeze). Can you please confirm that this is the resolution you are working at? "30k" is shorthand for "30,000", which is very large for any image. This resolution seems a bit unmaintainable as a workflow for any reasonably sized project, so I would guess you are actually working at 3000x2000 (3k x 2k), and not 30000x20000, but would like clarification to be sure. You also mentioned using an "SD plugin" a quick search for this finds Stable Diffusion related plugins. While this could impact Krita's performance as well, that alone shouldnt be the cause of slow saves or freezes. However I recommended testing things to confirm you can reproduce the problem without any plugins installed/enabled as well. Whether this is more of a feature request than a bug report, I do agree that being able to export layers separately from full-project save operations may be a good emergency recovery option, in the event a full-save ends up frozen. This would probably necessitate having such operations occur on a separate thread however. Finally, I have not encountered instances of a "frozen" save when normally working on projects on the 5.2.11 AppImage at smaller resolutions than what was reported, nor any versions later than that up to 5.3.3/6.0.3. Saves have been relatively quick and don't appear to freeze for more than a couple seconds on bigger, more complex works. The times I have had unrelated crashes, autosave backups managed to restore the majority of lost work as well. -- You are receiving this mail because: You are watching all bug changes.
