https://bugs.kde.org/show_bug.cgi?id=442972
Ahab Greybeard changed:
What|Removed |Added
CC||ahab.greybe...@hotmail.co.u
https://bugs.kde.org/show_bug.cgi?id=442972
Eoin O'Neill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Latest Commit|
https://bugs.kde.org/show_bug.cgi?id=442972
Eoin O'Neill changed:
What|Removed |Added
CC||eoinoneill1...@gmail.com
Status|CONF
https://bugs.kde.org/show_bug.cgi?id=442972
--- Comment #5 from Lynx3d ---
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
https://bugs.kde.org/show_bug.cgi?id=442972
--- Comment #4 from sh_zam ---
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 happe
https://bugs.kde.org/show_bug.cgi?id=442972
Tiar changed:
What|Removed |Added
CC||tamtamy.tym...@gmail.com
Keywords|
https://bugs.kde.org/show_bug.cgi?id=442972
--- Comment #3 from Lynx3d ---
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 maste
https://bugs.kde.org/show_bug.cgi?id=442972
tomtomtomreportin...@gmail.com changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=442972
--- Comment #1 from Lynx3d ---
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 do
