https://bugs.kde.org/show_bug.cgi?id=408445
--- Comment #1 from Dmitrii Utkin <loen...@gmail.com> ---
Also I found that "paste image" tool decodes image ineffectively - it decodes
all supported variants and then chose one by the priority. In my test it was
decoding 4 times and Krita freezes for 6 seconds.. I'd like to optimize it too
by:
1) querying the clipboard image, return it in case of success
2) else traverse the supported mime-types in *order of priority* and try to
decode the image, return it in case of success
In addition to 5) there is a KisClipboard::clipboardDataChanged() slot which
freezes Krita for few seconds when you copy a large image to clipboard and just
switch to Krita/create new image. The way of detecting "is there an image" is
unreliable too. "cb->image()" just decodes (and freezes Krita) the main image
without respecting the multi-mime-type images. There should be a way to detect
clipboard image data without full reading of the image. Maybe QImageReader or
QImageIOHandler is the way to go.
For me this piece of code looks strange:
if (cb->mimeData()->hasImage()) {
QImage qimage = cb->image();
if (!qimage.isNull())
m_hasClip = true;
const QMimeData *cbData = cb->mimeData();
QByteArray mimeType("application/x-krita-selection");
if (cbData && cbData->hasFormat(mimeType))
m_hasClip = true;
}
I think it may be rewritten like this without losing anything (in exception of
freeze):
if (cb->mimeData()->hasImage()) {
m_hasClip = true;
}
For now I just leave it as is, because it needs more testing. Maybe will
re-create it as a new bug.
--
You are receiving this mail because:
You are watching all bug changes.
