Skip to content

Avoid laggy panning/zooming of Perspective assistant

Nabil Maghfur Usman requested to merge nmaghfurusman/krita:nabil/perspective-assistant-bug-411352 into krita/4.4.2

2020-12-04-15_15_47

Fix for https://bugs.kde.org/show_bug.cgi?id=411352, achieved by not using the drawCache function to draw Perspective assistants, since the pixmap cache gets constantly flushed and repopulated anyway when the user pans/zooms the canvas up close to a Perspective Assistant, at which point they will experience a noticeably reduced frame rate (eg panning like in the attached picture will be very choppy).

The drawback of course is that the Perspective assistant does not take advantage of caching anymore, but this isn't really an issue since the Vanishing Point assistant also doesn't use caching (except to draw the "X"), it doesn't cause the canvas to noticeably stutter even if you make its gridlines as dense as possible.

Another drawback is that the Perspective assistant's gridlines are now aliased (see picture).

Additional Notes

I suspect there are deeper issues that could still be addressed here, since there's no good reason why putting draw code in drawCache should be as visibly expensive to framerate as it is. All that's being done is redrawing antialiased lines after all.

I've settled for this particular solution since it's straightforward and makes the Perspective assistant code appear more consistent with the Vanishing Point assistant code.

Test Plan

  • Canvas does not stutter when panning around while up close to Perspective assistant
  • View->Show Painting Assistant still works as expected
  • View->Show Assistant Preview still works as expected
  • Per-assistant snapping (middle icon of the on-canvas widget) still works as expected

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Merge request reports