I'm assuming that this may be due to the fact that the computer is re-drawing the image with a specific pixel lookup? (Bilinear or bicubic?) However, the performance drop would only make sense if the reference image was being moved at such a size; I'm simply drawing on the canvas and it's choking performance. https://drive.google.com/file/d/10ROu8fKPLP15T87ND3d0RC7jiVBsTHKb/view?usp=sharing (I'm not sure if that was a glitch with the Overview docker in the video or not...)
I can confirm a delay on the brush stroke view, although not necessarily a performance slow down of Krita as other functions (like bucket fill, shapes, etc) work just fine. What I notice is the following: -A big image (around more than half a given canvas) will trigger a delay on the stroke, and makes it look glitchy too, which in my case I think is the mayor problem as the delay itself just feels as when using heavy values on the stabilizer mode. -The original size of the image is not important as it is its displayed size on the canvas, thus a big image, once downsized will not trigger the problem. -The position of the image within the canvas doesn't change the outcome of the previous points. I can see this behavior on the latest master-git build, Archlinux/Plasma + Nvidia here.
I'm glad you tested it and was able to achieve the same results. I wasn't sure if the slowdown was the entire application or just the brush. The reference images tool is a nice feature, but when I experienced this, it was quite surprising, especially for the images that I embedded into the .kra project file.
Jouni, Can you take a look?
Git commit 380e271df5b01d5badd07d609b9e19769751a1be by Jouni Pentikäinen. Committed on 04/05/2018 at 14:42. Pushed by jounip into branch 'master'. Fix constant redrawing of reference images M +1 -0 libs/ui/KisReferenceImagesDecoration.cpp https://commits.kde.org/krita/380e271df5b01d5badd07d609b9e19769751a1be