Bug 399363

Summary: Can't move a rectangle
Product: [Applications] krita Reporter: Jaime Torres <jtamate>
Component: Layers/VectorAssignee: Emmet O'Neill <emmetoneill.pdx>
Status: RESOLVED FIXED    
Severity: grave CC: halla
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: the file that triggers the problem
A callgrind output of the problem

Description Jaime Torres 2018-10-04 07:22:51 UTC
Created attachment 115404 [details]
the file that triggers the problem

SUMMARY
It is impossible to move the bad placed black rectangle into the upper right corner (with or without HW acceleration).

STEPS TO REPRODUCE
1. Open the attached file
2. Select the bad placed back rectangle
3. Try to move it to the upper right corner

OBSERVED RESULT
Running it under callgrind, I see 30.000.000 calls to an unknown Qt method (0x00000000003457b0).

SOFTWARE VERSIONS
Krita
  Version: 4.2.0-pre-alpha (git 230fb0b)

Qt
  Version (compiled): 5.11.1
  Version (loaded): 5.11.1

ADDITIONAL INFORMATION
This could be a Qt bug.
Comment 1 Halla Rempt 2018-10-04 07:32:37 UTC
Yes, something is locked up in that file.
Comment 2 Jaime Torres 2018-10-07 08:41:22 UTC
Created attachment 115459 [details]
A callgrind output of the problem

The Qt method where it gets blocked is: gray_render_scanline
called (indirectly) from KoShapeStroke::Private::paintBorder
Created Qt bug: https://bugreports.qt.io/browse/QTBUG-70978
Comment 3 Halla Rempt 2018-10-07 09:14:53 UTC
I think it might still be our bug, though.
Comment 4 Jaime Torres 2018-10-07 09:28:02 UTC
Maybe there are really two bugs to fix ;-)
Not painting the border while moving?
Taking so much time to fill a path.
Comment 5 Emmet O'Neill 2018-10-14 20:51:52 UTC
Git commit 3f6177619dcc756e84be1f9254c46fb1f56371c3 by Emmet O'Neill.
Committed on 14/10/2018 at 20:35.
Pushed by emmetoneill into branch 'master'.

Improved responsiveness of moving large SVG objects.

Added a KisSignalCompressor to the KisShapeLayerCanvas to reduce the
number of updates.

M  +1    -2    libs/flake/KoShape.cpp
M  +0    -2    libs/flake/KoShape.h
M  +0    -1    libs/flake/KoShapeManager.h
M  +1    -0    libs/flake/KoShapeStroke.cpp
M  +22   -19   libs/ui/flake/kis_shape_layer_canvas.cpp
M  +2    -0    libs/ui/flake/kis_shape_layer_canvas.h

https://commits.kde.org/krita/3f6177619dcc756e84be1f9254c46fb1f56371c3
Comment 6 Halla Rempt 2018-11-20 08:58:37 UTC
Git commit dc4e44f448ba5fc8379ac7751baf2638593b0ac0 by Boudewijn Rempt, on behalf of Emmet O'Neill.
Committed on 20/11/2018 at 08:22.
Pushed by rempt into branch 'krita/4.1'.

Improved responsiveness of moving large SVG objects.

Added a KisSignalCompressor to the KisShapeLayerCanvas to reduce the
number of updates.

M  +1    -2    libs/flake/KoShape.cpp
M  +0    -2    libs/flake/KoShape.h
M  +0    -1    libs/flake/KoShapeManager.h
M  +1    -0    libs/flake/KoShapeStroke.cpp
M  +22   -19   libs/ui/flake/kis_shape_layer_canvas.cpp
M  +2    -0    libs/ui/flake/kis_shape_layer_canvas.h

https://commits.kde.org/krita/dc4e44f448ba5fc8379ac7751baf2638593b0ac0
Comment 7 Halla Rempt 2019-03-21 15:53:10 UTC
Git commit 861995e810b1ecfa5260903fd58ef89f199d3bc3 by Boudewijn Rempt.
Committed on 21/03/2019 at 15:53.
Pushed by rempt into branch 'master'.

Shape layers: change the canvas compressor delay depending on image size

This sort of keeps the best of both the fix for
https://bugs.kde.org/show_bug.cgi?id=399363 and some responsiveness
for smaller images.

The real solution probably would be to render the vector shapes at
the current zoom level, LoD-like (and only for the visible part,
of course), but that's way out of scope for now. We might as well
wish we could write our svg renderer without QPainter and with
proper color management.
Related: bug 405698

M  +15   -2    libs/ui/flake/kis_shape_layer_canvas.cpp
M  +2    -2    libs/ui/flake/kis_shape_layer_canvas.h

https://commits.kde.org/krita/861995e810b1ecfa5260903fd58ef89f199d3bc3