Summary: | Copy/Cut became very slow and bugged | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Lynx3d <lynx.mw+kde> |
Component: | Layer Stack | Assignee: | Eoin O'Neill <eoinoneill1991> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahab.greybeard, eoinoneill1991, tamtamy.tymona, tomtomtomreportingin |
Priority: | NOR | Keywords: | regression, release_blocker |
Version: | git master (please specify the git hash!) | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/c00ecf945aee90d7f3601508bfc3b4235ef05693 | Version Fixed In: |
Description
Lynx3d
2021-09-26 10:22:13 UTC
I did a bit of digging to find out what takes so long. Turned out it is: KisMimeData::retrieveData(mimetype = "application/x-qt-image", preferredType = QVariant::QImage) It takes so long because it creates a temporary document with the size of the original image, and pulls the projection from it, and converts it to QImage. This takes ~3s even for something as small as 1000x1000 pixels. I don't really understand why "cb->setMimeData(data);" in KisClipboard::setLayers() immediately triggers the QImage conversion, or why creating a new document is so insanely expensive, or why it is done for a single layer now in the first place, and why it is not cropped to the actual selection that was copied. Confirming. Are you positive that the poor performance is not also observable in 5.0? On my end, cutting three layers in 4.4.7 is basically perfectly smooth while cutting three empty layers in 5.0 beta 1 provides fairly jank performance for several seconds after the operation. Hm I can't reproduce it with Krita 5.0 appimages here, copying the 10 color layers of a 4k image I'm working on and opening the File->New dialog only takes maybe half a second to evaluate the clipboard content, while master branch takes 4+ seconds for each of those same actions. If memory serves me correctly, compiling 5.0 branch myself didn't show the issue either. But something seems to have made creating a new document object (not only an actual document to edit with canvas etc. but also temporary/internal ones) extremely slow, even a blank one. I just hadn't time yet to investigate what's going on...it's quite possible it can happen in 5.0 branch too in certain conditions. Hi, Okay, I ran this in profiler and the performance numbers between Krita 4 and 5 (beta) seem to be consistent, where the maximum time during the operation was spent in some functions in zlib. This doesn’t seem to happen with master and it seems to run faster.. I must be doing something wrong, or probably the issue has been fixed? Yes something seems to have changed, although I have no idea which commit(s) could be responsible. The freezing on copy seems gone on master here. But one regression remains, and it seems to be caused by layers with a non-transparent default pixel. If you copy and paste from such a layer, the new layer will be filled entirely with the source's default pixel, and that's also causing the unexpected dimensions on the "Create from Clipboard" page of the new document dialog. Git commit c00ecf945aee90d7f3601508bfc3b4235ef05693 by Eoin O'Neill. Committed on 27/11/2021 at 11:13. Pushed by eoinoneill into branch 'master'. Fix regression where default-pixel would persist when trimming layer contents. M +12 -0 libs/ui/actions/kis_selection_action_factories.cpp https://invent.kde.org/graphics/krita/commit/c00ecf945aee90d7f3601508bfc3b4235ef05693 As noted in https://bugs.kde.org/show_bug.cgi?id=446091 The Copy/Cut action is still very slow for the Nov 27 5.1.0-prealpha (git 72b21b1) appimage. |