Bug 442972 - Copy/Cut became very slow and bugged
Summary: Copy/Cut became very slow and bugged
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: git master (please specify the git hash!)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Eoin O'Neill
URL:
Keywords: regression, release_blocker
Depends on:
Blocks:
 
Reported: 2021-09-26 10:22 UTC by Lynx3d
Modified: 2021-11-28 08:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lynx3d 2021-09-26 10:22:13 UTC
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
Comment 1 Lynx3d 2021-09-29 20:09:39 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.
Comment 2 tomtomtomreportingin 2021-10-03 07:26:47 UTC
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.
Comment 3 Lynx3d 2021-10-03 20:42:03 UTC
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.
Comment 4 sh_zam 2021-10-28 21:33:34 UTC
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?
Comment 5 Lynx3d 2021-10-31 16:49:22 UTC
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.
Comment 6 Eoin O'Neill 2021-11-27 11:14:39 UTC
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
Comment 7 Ahab Greybeard 2021-11-28 08:00:31 UTC
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.