Bug 411334 - Editing vector object does not redraw canvas correctly
Summary: Editing vector object does not redraw canvas correctly
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Vector (show other bugs)
Version: git master (please specify the git hash!)
Platform: Other macOS
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-27 01:59 UTC by vanyossi
Modified: 2019-09-13 09:59 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
vector artifacts, incorrect redraw. (19.36 KB, image/png)
2019-08-27 01:59 UTC, vanyossi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vanyossi 2019-08-27 01:59:56 UTC
Created attachment 122379 [details]
vector artifacts, incorrect redraw.

I stumbled upon this.

In master(bd00a058145ad0) editing a vector shape does not redraw boundaries correctly leaving traces of the old shape behind

This does not happen on 4.2.5


STEPS TO REPRODUCE
1. Create vector layer and add a shape
2. convert shape to path if it isnt
3. Edit shape moving control points

OBSERVED RESULT
artifacts


EXPECTED RESULT
no artifacts

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2019-08-27 05:57:51 UTC
Confirmed. I guess you'll have to bisect this.
Comment 2 vanyossi 2019-08-29 16:46:41 UTC
Bug intruduced by

commit bbc0f80732afbf0cb36ccdf5fd6b672dd15712a6
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Fri Jul 12 20:02:22 2019 +0300

    Refactor signal compressor to have better timing properties
    
    * before: emits signals with time range [1.0...2.0] * interval
    * after: emits signals with time range [0.5...1.5] * interval
    
    Bascially, now it handles it much better when interval is around
    10-20 ms. With the old version it caused KisCanvas2 to drop frames
    and look ugly when the user pans the canvas.
    
    CCBUG:409460
Comment 3 Dmitry Kazakov 2019-08-30 12:53:44 UTC
Git commit 21977037e6231b727274bd73d9d1394f479377f4 by Dmitry Kazakov.
Committed on 30/08/2019 at 12:53.
Pushed by dkazakov into branch 'master'.

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/21977037e6231b727274bd73d9d1394f479377f4
Comment 4 Dmitry Kazakov 2019-08-30 12:53:44 UTC
Git commit bec9bf1faa6fd83d9b6a5df39c27c5ed081359c3 by Dmitry Kazakov.
Committed on 30/08/2019 at 12:53.
Pushed by dkazakov into branch 'master'.

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/bec9bf1faa6fd83d9b6a5df39c27c5ed081359c3
Comment 5 Dmitry Kazakov 2019-09-13 09:59:53 UTC
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 Dmitry Kazakov 2019-09-13 09:59:53 UTC
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