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
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.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/784
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
*** Bug 434866 has been marked as a duplicate of this bug. ***
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
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