https://bugs.kde.org/show_bug.cgi?id=377142
Probably in two places:
- the rate of issuing setX/setY is too high (usially it is constant time, but in WA mode it is O(n^2))
- the rate of update calls is too high
https://bugs.kde.org/show_bug.cgi?id=377142
Probably in two places:
While I'd say that this is unrelated to the linked bug report, I think it's worth a mention that it's slower to use the move tool with the layer docker visible.
When moving while the layer docker is visible, kritarc is accessed at fairly regular intervals, leading to a brief pause in motion.
(This happens in 3.2 and master)
I suspect that it's KisNodeDelegate::drawThumbnail()
There are no more periodic accesses after commenting out the five lines involving "cfg" inside that function.
Edit 2017-08-28 11:17z: To keep some additional information in one place:
06:42 < nicholasl> boud: Separately from what I just wrote on Phabricator, I noticed that reads from kritarc are extremely frequent (perhaps every time the mouse moves) when moving when not using OpenGL.
06:44 < nicholasl> (and that happens regardless of the layer docker's visibilty)
07:06 < nicholasl> boud: The no-OpenGL one looks to be caused by KisCoordinatesConverter::getQPainterCheckersInfo(), called from KisQPainterCanvas::paintEvent()
(After rereading my IRC message, it seems like "moving when not using OpenGL" could be read to mean moving the mouse on the canvas; however, I am only referring to using the move tool.)
Both cases of kritarc accesses I mentioned are now fixed with commits e97f50912718f114686593d365a275ce86df61ac (krita/3.2) and 1da3b038dcd824c8b138bfdee6aa3aa0262b7de5 (master).