Bug 422204 - Strokes with gradients mess up the fill colors
Summary: Strokes with gradients mess up the fill colors
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Vector (show other bugs)
Version: 4.2.9
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 434866 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-29 01:17 UTC by Jonathan Z Gilbert
Modified: 2021-06-08 07:28 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
different fill gradient display for shapes with/without stroke gradient (245.30 KB, image/jpeg)
2020-05-29 01:17 UTC, Jonathan Z Gilbert
Details
Test file (96.80 KB, application/x-krita)
2020-05-30 00:56 UTC, vanyossi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Z Gilbert 2020-05-29 01:17:11 UTC
Created attachment 128894 [details]
different fill gradient display for shapes with/without stroke gradient

SUMMARY
This is very similar to bug 399127 but I'm also seeing some behaviors not described there, plus that bug is already marked "fixed", so I wasn't sure if comments added to it would be seen.  I'll take you through a few stages of what I'm observing.

STEPS TO REPRODUCE
1. Create a vector shape and select it with the Select Shapes tool.
2. In Tool Options, select Fill tab and set it to either no fill or a solid color not the foreground color.
3. Select Stroke tab and set to gradient.

OBSERVED RESULT
Shape fills with foreground color.  Note that if you return to the Fill tab and attempt to change the fill color, it will not change.  So far this is still bug 399127.  Let's continue.

4. Create a second shape, shape 2, and select it.
5. In Tool Options, set stroke to None and fill to Gradient, either linear or radial.
6. Edit or at least select one of the stops of the fill gradient.
7. Select shape 1 again (the one with the gradient stroke).

OBSERVED RESULT:
Shape 1's fill becomes the same type of gradient as shape 2, where it was not a gradient before.  I *think* I'm also seeing that the colors match shape 2's gradient except that the color of the stop you selected is replaced with the foreground color, but I haven't verified that.

By the way, note at this point that if you look at the Fill tabs of both shape 1 and shape 2, the gradient bar displays are not the same style -- see attachment.

8. Select shape 1, Fill tab.  Click on any stop of the gradient.

OBSERVED RESULT:
The color of the stop is replaced with the foreground color and cannot be changed away from it.

I tried some other combinations of gradient-stroke, no-stroke, and solid-stroke shapes.  As far as I can tell, shapes with solid strokes work just fine.  With the other combinations there were some other weird behaviors, especially when gradient fills were involved too, but this is as far as I can get with systematically reproducing and describing them.

SOFTWARE/OS VERSIONS
Windows: Windows 10
Krita

 Version: 4.2.9
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.7
  Version (loaded): 5.12.7

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.18362
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
 
  Vendor:  "Intel" 
  Renderer:  "Intel(R) HD Graphics" 
  Version:  "4.0.0 - Build 10.18.10.4303" 
  Shading language:  "4.00 - Build 10.18.10.4303" 
  Requested format:  QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
  Current format:    QSurfaceFormat(version 4.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
     Version: 4.0
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: false 

Hardware Information

  GPU Acceleration: none
  Memory: 3976 Mb
  Number of Cores: 4
  Swap Location: C:/Users/Jonathan/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/Jonathan/AppData/Local/Temp
  Undo Enabled: 1
  Undo Stack Limit: 30
  Use OpenGL: 0
  Use OpenGL Texture Buffer: 1
  Use AMD Vectorization Workaround: 0
  Canvas State: OPENGL_SUCCESS
  Autosave Interval: 900
  Use Backup Files: 1
  Number of Backups Kept: 1
  Backup File Suffix: ~
  Backup Location: Same Folder as the File
  Use Win8 Pointer Input: 0
  Use RightMiddleTabletButton Workaround: 0
  Levels of Detail Enabled: 0
  Use Zip64: 0


Display Information
Number of screens: 1
	Screen: 0
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
Comment 1 vanyossi 2020-05-30 00:56:32 UTC
Created attachment 128924 [details]
Test file

This bug is related to bug 399127 as it only happens if the shape has stroke gradient fill.

Test file provided.

Use select tool. Click on shape 2, then click on shape 1.

Shape one will get shape 2 fill gradient style.

NOTE: on Linux when performing original reporter steps the second shape is created with no stroke and no fill, appearing invisible in canvas.
Comment 2 Bug Janitor Service 2021-03-31 22:17:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/784
Comment 3 Dmitry Kazakov 2021-04-01 05:49:18 UTC
Git commit 1fffa7e33fb5581e2f379dc77101aa712830bc01 by Dmitry Kazakov, on behalf of Sharaf Zaman.
Committed on 01/04/2021 at 05:48.
Pushed by dkazakov into branch 'master'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 399127, bug 434828

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/1fffa7e33fb5581e2f379dc77101aa712830bc01
Comment 4 Halla Rempt 2021-04-08 13:20:06 UTC
*** Bug 434866 has been marked as a duplicate of this bug. ***
Comment 5 sh_zam 2021-06-08 07:22:13 UTC
Git commit 69ac8b85e49bcd11d100a770549d4c89fecae5a8 by Sharaf Zaman.
Committed on 08/06/2021 at 07:21.
Pushed by szaman into branch 'krita/4.3'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 399127, bug 434828
(cherry picked from commit 1fffa7e33fb5581e2f379dc77101aa712830bc01)

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/69ac8b85e49bcd11d100a770549d4c89fecae5a8
Comment 6 sh_zam 2021-06-08 07:28:40 UTC
Git commit 27a6d0eebce1c9fa29ddd023d5df898da01f27e6 by Sharaf Zaman.
Committed on 08/06/2021 at 07:26.
Pushed by szaman into branch 'krita/4.4.5'.

Bugfix: Inconsistent stroke fill and shape fill

Problem: Embedding KoFillConfigWidget in KoStrokeConfigWidget created
codepaths which KisAcyclicSignalConnector doesn't block, which resulted
in an inconsistent behavior when both strokes and fill were used in a
shape.

Solution: By default if we hadn't embedded the widgets, signals from
ResourceManager would've been blocked by KisAcyclicSignalConnector when
we entered slotProposeCurrentColorToResourceManager. Since we don't, we
have to manually block events when we are in this method.
Related: bug 399127, bug 434828
(cherry picked from commit 1fffa7e33fb5581e2f379dc77101aa712830bc01)

M  +8    -0    libs/ui/widgets/KoFillConfigWidget.cpp

https://invent.kde.org/graphics/krita/commit/27a6d0eebce1c9fa29ddd023d5df898da01f27e6