Bug 461692 - Vector shapes swap colors have random memory
Summary: Vector shapes swap colors have random memory
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layers/Vector (show other bugs)
Version: 5.1.3
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: sh_zam
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-11 08:02 UTC by keyth_qcfx2
Modified: 2022-12-14 05:00 UTC (History)
1 user (show)

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


Attachments
Krita system information (14.56 KB, text/plain)
2022-11-12 02:28 UTC, keyth_qcfx2
Details

Note You need to log in before you can comment on or make changes to this bug.
Description keyth_qcfx2 2022-11-11 08:02:38 UTC
Selecting a vector shape and using swap color will randomly swap and not swap or keep in memory the background color when you return back


STEPS TO REPRODUCE
1. set a vector object with colors
2. press swap foreground with background colors to make the fill and outline colors to swap

OBSERVED RESULT
the object will sometimes swap colors correctly and other times it will remember the previous background color regardless if it was edited or not

EXPECTED RESULT
swap fill and outline colors of the object

SOFTWARE/OS VERSIONS
Windows: 10
Qt Version: 5.12.12

ADDITIONAL INFORMATION
Video Demonstration
https://krita-artists.org/uploads/default/original/3X/e/6/e6e238955b20cb7352f459986883a758ea472169.webm
Comment 1 sh_zam 2022-11-11 16:54:07 UTC
Hi! Can you please share the output of Help -> Show system information for bug reports?
Comment 2 keyth_qcfx2 2022-11-12 02:28:20 UTC
Created attachment 153682 [details]
Krita system information
Comment 3 Bug Janitor Service 2022-11-12 05:15:12 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 4 sh_zam 2022-11-14 05:59:00 UTC
You seem to be using pigment.o plugin. Can you please disable it and then retest? (see Bug 458913).
Comment 5 keyth_qcfx2 2022-11-14 18:57:33 UTC
As requested I tested it without Pigment.o installed in the system and it still does it, because all my testing was with Krita alone.


To elaborate on why pigment is not in the way :
Pigment.o was there in "read only" mode to assist me during this testing sessions.
Also the released Pigment.o does not own any colors never did and can't and shouldn't (contrary to popular belief alot of the time). What it does is a redundancy check once, and once only. If the color spirals out of control is because Krita READ color is different from Krita WRITE color which means Krita did not pass the test with itself. Also the FG and BG color are treated independently so swapping within Krita would not cause update lag in Pigment.o as itself uses the Krita action to swap colors and then it just reacts to it.

Adding to this version 2 (that I am using now) locks itself out of vectors because, vector layers haven't matched READ and WRITE for more than a year now. Before that vector layers were stable and everything was working. I have ignored this "pigmento bug" for a while since I would be correcting to probably to a Krita bug just to be reverted back again and having to redo it again, BUT alot of time has passed and no changes so I imagined it was really be a new way to do things with vectors. So I test to know how to do things ... But during my testing I just see it is just a collection of small bugs doing asynchrony that pass under the radar and not really a new way to do things as I was expecting now. So I report.
Comment 6 sh_zam 2022-11-18 17:48:26 UTC
Git commit 2dfa0d19cd176ef70c082c4970fc76e1b0116900 by Sharaf Zaman.
Committed on 18/11/2022 at 17:47.
Pushed by szaman into branch 'master'.

Bugfix: Vector shapes not swapping the current fg/bg color.

It is really difficult to see why this used to work before. But to get
to the reason for the bug, let's say we press the swap button on paintop
box. And the current active widget is "Fill" tab. So, the
KoFillConfigWidget (d->fillVariant = Fill) is activated. So, when we
swap the color, the color of Stroke is changed through the color of
Fill, but the d->colorAction's color is that of the fill, but since we
are swapping it for Stroke. The if (currentKoColor() == color) returns
true and this we skip swapping it for stroke.

We also fix the colorAction button for Stroke, it didn't work
properly (for the same reason, Fill changed the color back to what it
was when swapping).

(A TODO for future (which maybe somewhere near, given some things are
still buggy with this file), we really have to decouple Stroke and Fill
types).

M  +4    -5    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/2dfa0d19cd176ef70c082c4970fc76e1b0116900
Comment 7 sh_zam 2022-11-21 09:57:30 UTC
Hello! I have fixed the issue, I would really appreciate if you could test the nightly -- since this part of code is something which has been buggy for quite some time now.
Comment 8 keyth_qcfx2 2022-11-27 01:54:37 UTC
version : krita-nightly-x64-5.2.0-prealpha-9cb8ac659f seems to be working I cannot trigger it anymore as I was doing it before. with and without pigmento on the mix. I would say this one is fixed. thank you.
Comment 9 sh_zam 2022-11-27 15:17:43 UTC
Thank you for testing!
Comment 10 sh_zam 2022-12-14 05:00:44 UTC
Git commit 9f2751f236e48280c70a96178ede93051f7575ae by Sharaf Zaman.
Committed on 14/12/2022 at 04:59.
Pushed by szaman into branch 'krita/5.1'.

Bugfix: Vector shapes not swapping the current fg/bg color.

It is really difficult to see why this used to work before. But to get
to the reason for the bug, let's say we press the swap button on paintop
box. And the current active widget is "Fill" tab. So, the
KoFillConfigWidget (d->fillVariant = Fill) is activated. So, when we
swap the color, the color of Stroke is changed through the color of
Fill, but the d->colorAction's color is that of the fill, but since we
are swapping it for Stroke. The if (currentKoColor() == color) returns
true and this we skip swapping it for stroke.

We also fix the colorAction button for Stroke, it didn't work
properly (for the same reason, Fill changed the color back to what it
was when swapping).

(A TODO for future (which maybe somewhere near, given some things are
still buggy with this file), we really have to decouple Stroke and Fill
types).
(cherry picked from commit 2dfa0d19cd176ef70c082c4970fc76e1b0116900)

M  +4    -5    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/9f2751f236e48280c70a96178ede93051f7575ae