Bug 413220 - Weird connections among selected areas
Summary: Weird connections among selected areas
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Selection (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR minor
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
: 418568 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-20 05:59 UTC by acc4commissions
Modified: 2020-05-08 17:19 UTC (History)
4 users (show)

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


Attachments
file (482.98 KB, application/x-krita)
2019-10-20 05:59 UTC, acc4commissions
Details

Note You need to log in before you can comment on or make changes to this bug.
Description acc4commissions 2019-10-20 05:59:44 UTC
Created attachment 123350 [details]
file

SUMMARY
git e444d22

https://forum.kde.org/viewtopic.php?f=288&t=162791

When selecting areas with selection tools, these unexpected lines of marching ants appear.

It's not a new behaviour. It also happens with 4.2.7.


STEPS TO REPRODUCE
1. Select bunch of areas with selection tools.
2. Adjust zoom level with mouse to see the connection.

OBSERVED RESULT
Flickery lines appear among selection areas.

EXPECTED RESULT
No lines.

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

ADDITIONAL INFORMATION

In the attatched file, it can be seen the most often in zoom level 50, 67. 

Turns out it does not only happen with contiguous selection tool, and it seems the 'lines' are connected in the order you made the selection areas.

I didn't manage to reproduce this with outline selection tool yet.
Comment 1 Halla Rempt 2019-10-21 07:46:40 UTC
I can confirm the issue with your test file. Surprisingly, the connections are kind of animated :-)
Comment 2 Halla Rempt 2019-10-21 07:52:47 UTC
I've tested some older appimages, and this happens from at 3.0.0. Curious that nobody else has seen it before, since 67% zoom is a default step.
Comment 3 Tiar 2020-03-07 17:24:55 UTC
*** Bug 418568 has been marked as a duplicate of this bug. ***
Comment 4 Dmitry Kazakov 2020-05-08 12:45:40 UTC
*** Bug 419240 has been marked as a duplicate of this bug. ***
Comment 5 Dmitry Kazakov 2020-05-08 17:18:49 UTC
Git commit c15d8888c3d793a31c914ffb80a5b38a1f2846ad by Dmitry Kazakov.
Committed on 08/05/2020 at 17:18.
Pushed by dkazakov into branch 'master'.

Fix artifacts when rendering complex selection outlines

It happens because of a bug in opengl-based stroking algorithm in Qt.
And it happens only when one tries to draw a path with multiple
subpaths. The easiest workaround for this bug without patching Qt is
to manually split a multi-subpath path into QPainterPath objects with
only one subpath in each.

It might happen that the resulting subpath generated by the QDashStroker
will have no lines at all. It happens when further LineToElement items
compare as equal to the starting MoveToElement when compared in 'float'
space. In such case QTriangulatingStroker::process() skips LineTo elements
and the vertexBuffer ends up with unconnected vertices, which generate
unwanted triangles.
Related: bug 419240

A  +80   -0    3rdparty/ext_qt/0100-Fix-artifacts-when-rendering-multisubpath-dashed-QPa.patch
M  +5    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/kde/krita/commit/c15d8888c3d793a31c914ffb80a5b38a1f2846ad
Comment 6 Dmitry Kazakov 2020-05-08 17:19:29 UTC
Git commit 8208fa254321232105a231fc517541e98c747216 by Dmitry Kazakov.
Committed on 08/05/2020 at 17:19.
Pushed by dkazakov into branch 'krita/4.3'.

Fix artifacts when rendering complex selection outlines

It happens because of a bug in opengl-based stroking algorithm in Qt.
And it happens only when one tries to draw a path with multiple
subpaths. The easiest workaround for this bug without patching Qt is
to manually split a multi-subpath path into QPainterPath objects with
only one subpath in each.

It might happen that the resulting subpath generated by the QDashStroker
will have no lines at all. It happens when further LineToElement items
compare as equal to the starting MoveToElement when compared in 'float'
space. In such case QTriangulatingStroker::process() skips LineTo elements
and the vertexBuffer ends up with unconnected vertices, which generate
unwanted triangles.
Related: bug 419240

A  +80   -0    3rdparty/ext_qt/0100-Fix-artifacts-when-rendering-multisubpath-dashed-QPa.patch
M  +5    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/kde/krita/commit/8208fa254321232105a231fc517541e98c747216