Bug 428332 - Layers contained in groups that have masks render incorrectly in 4.4.0
Summary: Layers contained in groups that have masks render incorrectly in 4.4.0
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: 4.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-10-27 10:42 UTC by Hadrien
Modified: 2020-11-01 06:57 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
stripped down file (2.75 MB, application/x-krita)
2020-10-27 10:42 UTC, Hadrien
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hadrien 2020-10-27 10:42:49 UTC
Created attachment 132788 [details]
stripped down file

SUMMARY
Layers contained in groups that have masks render incorrectly in 4.4.0

STEPS TO REPRODUCE
1. observe that black frame and checkmarks are the only visible elements on the canvas.
2. turn off then on again the layers named "trait", "couleur_maison" and "couleur_foret".

OBSERVED RESULT
Layers should be visible immediately on opening the file, as they are set to visible.

EXPECTED RESULT
Layers have to be toggled off then on again to be visible. This only happens with layers that are contained in a group that has a mask. Toggling the mask however has no effect on the visibility of said layers.

SOFTWARE/OS VERSIONS
Only Krita 4.4.0
Windows 10

ADDITIONAL INFORMATION
GTX1660Ti (mobile gpu), 16GiB, screen res is fullHD, stock Krita settings (fresh install)
Comment 1 Hadrien 2020-10-27 10:44:19 UTC
Oops I accidentally swapped "observed result" and "expected result", but I think this is clear.
Comment 2 Halla Rempt 2020-10-27 10:45:24 UTC
Thank you for the report. I can confirm the issue and that it's a regression.
Comment 3 Dmitry Kazakov 2020-10-27 21:10:03 UTC
Git commit d6c78129bfeba8d608babe5e592226074a2f75d7 by Dmitry Kazakov.
Committed on 27/10/2020 at 21:09.
Pushed by dkazakov into branch 'krita/4.3'.

Fix loading masks with vector selections

Loading has become broken after commit from June 2020:
6f283ca981 Fix undo breakage after converting a pixel selecion into a vector one

After this change, when a selection is converted into a vector form,
the content of the pixel selection becomes discarded (due to a separate
undo history). Theoreticalll, the projection should become updated using
KisUpdateSelectionJob, but it happens too lately (because the image is
locked while loading). More than that, this job doesn't cause a setDirty()
for the parental node. It happens because we don't usually expect vector
selections to be edited on anything other than selection masks (it is just
not possible for anything other than selection masks).

This patch fixes the issue by calling selection->updateProjection()
explicitly. That is not ideal, because it makes the projection
recalculated twice, but it doesn't seem to be too critical.

The patch also skips loading pixel selection at all, if any vector
selection is present. There is no need for it anymore.

M  +32   -10   plugins/impex/libkra/kis_kra_load_visitor.cpp

https://invent.kde.org/graphics/krita/commit/d6c78129bfeba8d608babe5e592226074a2f75d7
Comment 4 Dmitry Kazakov 2020-10-27 21:10:32 UTC
Git commit 84ed943ed0c722b76cb8181870a3b6ff04420fdc by Dmitry Kazakov.
Committed on 27/10/2020 at 21:10.
Pushed by dkazakov into branch 'master'.

Fix loading masks with vector selections

Loading has become broken after commit from June 2020:
6f283ca981 Fix undo breakage after converting a pixel selecion into a vector one

After this change, when a selection is converted into a vector form,
the content of the pixel selection becomes discarded (due to a separate
undo history). Theoreticalll, the projection should become updated using
KisUpdateSelectionJob, but it happens too lately (because the image is
locked while loading). More than that, this job doesn't cause a setDirty()
for the parental node. It happens because we don't usually expect vector
selections to be edited on anything other than selection masks (it is just
not possible for anything other than selection masks).

This patch fixes the issue by calling selection->updateProjection()
explicitly. That is not ideal, because it makes the projection
recalculated twice, but it doesn't seem to be too critical.

The patch also skips loading pixel selection at all, if any vector
selection is present. There is no need for it anymore.

M  +32   -10   plugins/impex/libkra/kis_kra_load_visitor.cpp

https://invent.kde.org/graphics/krita/commit/84ed943ed0c722b76cb8181870a3b6ff04420fdc
Comment 5 Dmitry Kazakov 2020-10-27 21:11:16 UTC
Git commit 17546d3ae4afa732b0ecc48ade59c0c8417b128b by Dmitry Kazakov.
Committed on 27/10/2020 at 21:10.
Pushed by dkazakov into branch 'krita/4.4.0'.

Fix loading masks with vector selections

Loading has become broken after commit from June 2020:
6f283ca981 Fix undo breakage after converting a pixel selecion into a vector one

After this change, when a selection is converted into a vector form,
the content of the pixel selection becomes discarded (due to a separate
undo history). Theoreticalll, the projection should become updated using
KisUpdateSelectionJob, but it happens too lately (because the image is
locked while loading). More than that, this job doesn't cause a setDirty()
for the parental node. It happens because we don't usually expect vector
selections to be edited on anything other than selection masks (it is just
not possible for anything other than selection masks).

This patch fixes the issue by calling selection->updateProjection()
explicitly. That is not ideal, because it makes the projection
recalculated twice, but it doesn't seem to be too critical.

The patch also skips loading pixel selection at all, if any vector
selection is present. There is no need for it anymore.

M  +32   -10   plugins/impex/libkra/kis_kra_load_visitor.cpp

https://invent.kde.org/graphics/krita/commit/17546d3ae4afa732b0ecc48ade59c0c8417b128b
Comment 6 Hadrien 2020-11-01 06:57:45 UTC
Thank you so much !