| Summary: | File Saving is getting extremely slow | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Manga Tengu <mangatengu> |
| Component: | File formats | Assignee: | Halla Rempt <halla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ghevan, halla, lynx.mw+kde |
| Priority: | NOR | ||
| Version: | 4.3.0-beta1 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/183da0759c1ddfd30335480375bb7c0425ba08b9 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Manga Tengu
2020-05-15 21:36:45 UTC
forgot to say I have a 2018 macbook pro 15` with a good cpu. The saved file is 3508x6905px and has 16 layers How is the performance of that file on Linux/Windows? Or if you can, send me a link to the file so I can test if the speed is really abnormal on macos compared to other platforms. (you can send the link to my mail if the file cannotbe shared in public) Sadly I don't have a linux with a comparable CPU. I wish I could mail the original it but it's too big. So I made a few slimming operations and tested the performance along the way which led me to interesting infos: I flattened the image -> still as slow I made the image 2/3 of the size, it got from 45 to 35 seconds I filled the layer with solid white -> saves in 1 or 2 seconds. This is proportional to the size of the file btw. So My guess is the more the final image is complex and fragmented, the slower it gets. The more solid color zones there are, the faster it is... I'm mailing you the flattened reduced file so it's a tad lower than 20 mb and fits gmail. (still the image is slow and complex -> 35 sec per save). Fill it with white, it will save fast. Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information. Did you switch on "Trim files before saving" in the the file handling tab of the settings dialog? No I didn't, but I also tried manually trimming the file before saving as It was bleeding a lot -> no noticeable change. I can send you the sample file if your email can handle a 20mb file attachement. That shouldn't be a problem, but a google drive or dropbox link or weshare would be fine as well. Hm, that's a pretty simple image... And it does take quite a bit of time saving, though not 40 seconds. Let's see what's going on here... yes originally it was bigger and had lots of layers but it was too big to share via email or here. (didn't think of drive). So I simplified it and realized it was still very slow. 43 seconds seconds to be exact on my configuration: 2018 macbook pro 15` with a good cpu. Okay I dug a bit into this, for me it was mergedimage.png that ate the most amount of time compressing, and the reason is apparently that since this commit 4d609a56ef572b22ec9a712985e1927c7a0143d0 the compression level is now Z_BEST_COMPRESSION (level 9), because KoQuaZipStore::setCompressionEnabled(true) set this, while initially it is initialized with Z_DEFAULT_COMPRESSION (-1, which apparently is 6 internally for zlib). Using Z_DEFAULT_COMPRESSION gets the save time and file size pretty much identically to the old code used in krita 4.2.9 on the file I tested. The file size difference was pretty much negligible btw, ~200kB for a 23MB file for taking 3-4 times longer to save. This is very interesting indeed. Leads me to think the following: In my comics workflow I have LOTS of files and I do save a lot. Since the compression difference is not significant, can we configure krita through ui settings to compression to 0 ? Can we even save files without mergedimage.png embeded files ? Then being able to command line krita to generate those mergedimage.png on demand would be very welcome. Would that affect thumbnails btw ? The strange thing is, that _is_ a setting, "compress kra files more", so I'll have to check why this is happening, because it's off by default. Yes but what I understood is default level is 6, and "compress more" is 9. But as an extrem saver I'd like to know if we could set the level with a slider rahter than a checkbox so we can chose from 0 to 9 ? That's for formats like PNG and JPG, not KRA, and apparently it's the compression on the KRA file (which is a zip file) which is the problem, but that should be off by default. I'm looking into it now. Git commit f271ef9ac18d79013c99a8780691840d09d8dc4d by Boudewijn Rempt. Committed on 18/05/2020 at 10:14. Pushed by rempt into branch 'krita/4.3'. Do not compress the mergedimage.png file M +2 -0 plugins/impex/libkra/kis_kra_saver.cpp https://invent.kde.org/graphics/krita/commit/f271ef9ac18d79013c99a8780691840d09d8dc4d Git commit 183da0759c1ddfd30335480375bb7c0425ba08b9 by Boudewijn Rempt. Committed on 18/05/2020 at 10:15. Pushed by rempt into branch 'master'. Do not compress the mergedimage.png file (cherry picked from commit f271ef9ac18d79013c99a8780691840d09d8dc4d) M +2 -0 plugins/impex/libkra/kis_kra_saver.cpp https://invent.kde.org/graphics/krita/commit/183da0759c1ddfd30335480375bb7c0425ba08b9 Git commit 0458ece78da69d290ab0ebc5443919012d858a6d by Boudewijn Rempt. Committed on 18/05/2020 at 12:34. Pushed by rempt into branch 'krita/4.3'. Set the default compression for png files in stores to 3 M +1 -1 libs/ui/kis_png_converter.cpp https://invent.kde.org/graphics/krita/commit/0458ece78da69d290ab0ebc5443919012d858a6d Git commit 0ac3c5b05ef9075ea11759f7e6f24f7ad76f5b69 by Boudewijn Rempt. Committed on 18/05/2020 at 12:35. Pushed by rempt into branch 'master'. Set the default compression for png files in stores to 3 (cherry picked from commit 0458ece78da69d290ab0ebc5443919012d858a6d) M +1 -1 libs/ui/kis_png_converter.cpp https://invent.kde.org/graphics/krita/commit/0ac3c5b05ef9075ea11759f7e6f24f7ad76f5b69 |