https://bugs.kde.org/show_bug.cgi?id=411334

Dmitry Kazakov <dimul...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|https://invent.kde.org/kde/ |https://invent.kde.org/kde/
                   |krita/commit/bec9bf1faa6fd8 |krita/commit/aeec54c45b2562
                   |3d9b6a5df39c27c5ed081359c3  |f256678d66d10d2621ef181b81
                   |https://invent.kde.org/kde/ |https://invent.kde.org/kde/
                   |krita/commit/aeec54c45b2562 |krita/commit/bec9bf1faa6fd8
                   |f256678d66d10d2621ef181b81  |3d9b6a5df39c27c5ed081359c3

--- Comment #5 from Dmitry Kazakov <dimul...@gmail.com> ---
Git commit aeec54c45b2562f256678d66d10d2621ef181b81 by Dmitry Kazakov.
Committed on 13/09/2019 at 08:56.
Pushed by dkazakov into branch 'krita/4.2'.

Fix artifacts when moving control points of path shape

In older (non-multithreaded) days calligra used extremely
hackish way of updating vactor shapes. It first called shape->update(),
then changed shape, then called shape->update() again. It could only work
when the updates were guaranteed to be queued and parsed in the next
window paint event. We don't have this guarantee in Krita for years,
so this method just cannot work. Instead, we should manually aggregate
dirty rect in the call and then call
shape->updateAbsolute(oldDirtyRect | shape->boundingRect). That is the only
way to guarantee that updates will happen correctly.

M  +2    -2    libs/flake/commands/KoPathControlPointMoveCommand.cpp
M  +4    -3    libs/flake/commands/KoPathPointMoveCommand.cpp

https://invent.kde.org/kde/krita/commit/aeec54c45b2562f256678d66d10d2621ef181b81

--- Comment #6 from Dmitry Kazakov <dimul...@gmail.com> ---
Git commit b92431e2c48d8d2c94204eb8ecbc8983eda64071 by Dmitry Kazakov.
Committed on 13/09/2019 at 08:56.
Pushed by dkazakov into branch 'krita/4.2'.

Fix extremely slow dragging of points in a shape with KoPathTool

The update signal must be compressed. We already have a compression
in KisShapeLayerCanvas, but there is no compression in
KoToolProxy::repaintDecorations().

M  +44   -6    libs/flake/KoShapeManager.cpp
M  +1    -0    libs/flake/KoShapeManager.h
M  +9    -2    libs/flake/KoShapeManager_p.h

https://invent.kde.org/kde/krita/commit/b92431e2c48d8d2c94204eb8ecbc8983eda64071

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to