SUMMARY Using Copy (Ctrl+C) or Cut (Ctrl+X) on a single layer became a lot slower, taking easily 3-4 seconds even on smallish images, while it used to be pretty much instant. It does not seem to matter if you have a selection or how big that selection is, it's always slow. Also, when there is something in the clipboard from such an operation, creating a new image (Ctrl+N) takes very long to open the dialog too, plus the image size in "Create from Clipboard" is wrong, it's always the whole document size from where you copied, not the expected size of the copied/cut portion. Note that the 5.0 branch is no affected, it must be something newer, possibly the merge of "Operations on multiple layers/groups" (!888) STEPS TO REPRODUCE 1. Create an image, something like screen resolution will do 2. Select a small portion of it with any selection tool 3. Cut the selection (Ctrl+X) 4. Open "New Image" dialog (Ctrl+N) 5. Go to "Create from Clipboard" section OBSERVED RESULT Step 3 and 4 take unusually long. Step 5 does not give the correct image size (compared to Krita 4.x) but the the image size created in Step 1. Also, if you close the current document between Step 3 and 4, krita will even crash with: ASSERT (krita): "hash != KeyTraits::NullHash" in file (...)/libs/image/3rdparty/lock_free_map/leapfrog.h, line 161 SYSTEM INFORMATION Krita Version: 5.1.0-prealpha (git 0a92c54) Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en Hidpi: true Qt Version (compiled): 5.15.3 Version (loaded): 5.15.3 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.4.0-86-generic Pretty Productname: Ubuntu 20.04.3 LTS Product Type: ubuntu Product Version: 20.04 Desktop: KDE OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 960/PCIe/SSE2" Version: "4.6.0 NVIDIA 460.91.03" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 15952 Mb Number of Cores: 4 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 150 Use OpenGL: true Use OpenGL Texture Buffer: true Disable Vector Optimizations: false Disable AVX Optimizations: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 1 Screen: 0 Name: DP-0 Depth: 24 Scale: 1 Resolution in pixels: 2560x1440 Manufacturer: BNQ Model: BenQ PD2705Q- Refresh Rate: 59.9506
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.