[krita] [Bug 476776] Performance drop with In-stack preview for Transform Tool
https://bugs.kde.org/show_bug.cgi?id=476776 --- Comment #5 from Dorijan Salak --- Just dropping in with more info. This turns out to be a slowdown caused by Continuous Transform functionality of transform tool, where it stores/recalls previous transform. Confirmed that hitting Esc button, Reset within tool options docker or choosing another tool will remove the performance drops. However the slowdown will resurface every time transform operation is done and again have to confirm any resize/scale/shear etc, then reset/Esc then moving will be faster. The part where performance returns to normal when adding/removing layer to the stack is due to the fact that this also resets previous transform. Unsure if this would still be considered a bug or "working as intended". It could be some issue with optimization in Continuous Transform or maybe this is the best it can be. Although in my opinion, it's weird that the performance drop is so impactful, where even a single pixel rotation/resize will make repositioning extremely slow. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 477715] [Selection tools] Tracing interupted by Krita while using Recorder docker (and recording)
https://bugs.kde.org/show_bug.cgi?id=477715 Dorijan Salak changed: What|Removed |Added CC||dorijan.sa...@gmail.com --- Comment #1 from Dorijan Salak --- Adding some extra info to this. It's caused by recorder taking a snapshot (set by Capture interval) so easiest to reproduce it is to set capture interval low like 1 sec, take freehand selection tool make a selection and then quickly start tracing new selection or add to current, after set interval a new capture will happen and interrupt current tracing. A way to avoid it is to wait the set interval before making a new selection, however it will still capture new snapshot for every addition to the selection. Capturing selection actions is a waste of storage space as selections won't even be visible during timelapse and instead only show as pause without any update to the timelapse for a duration it took to finish selection. Solution to this would be to simply exclude selection tool actions from being recorded, both for optimization reasons and to resolve this bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 477753] Cursor and stroke delay on transparent (empty) canvas at the end of each stroke
https://bugs.kde.org/show_bug.cgi?id=477753 --- Comment #1 from Dorijan Salak --- Created attachment 163638 --> https://bugs.kde.org/attachment.cgi?id=163638=edit Screen recording of steps to reproduce bug Uploaded screen recording to attachments. Also noticed that there is a delay in selecting layers as well, on top of stroke/cursor delays shorty after emptying canvas background (can be seen around the the 1:30 mark of the recording). The origin of the bug could be somewhere within the Layer stack. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 477753] New: Cursor and stroke delay on transparent (empty) canvas at the end of each stroke
https://bugs.kde.org/show_bug.cgi?id=477753 Bug ID: 477753 Summary: Cursor and stroke delay on transparent (empty) canvas at the end of each stroke Classification: Applications Product: krita Version: 5.2.1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: dorijan.sa...@gmail.com Target Milestone: --- SUMMARY Delays and painting performance drops when painting on empty (transparent) canvas with 2 or more layers in stack. STEPS TO REPRODUCE 1. Create new document (larger, something demanding) with 2 layers and Image Background opacity set to 0% 2. Attempt to draw multiple fast strokes 3. Observe cursor/stroke delay 4. Delete one layer so only 1 layer is in stack, or add 1-100% fill underneath, or increase image bg opacity to 0,05-100% 5. Repeat from step 2. to observe normal behavior OBSERVED RESULT Delay in cursor movement and stroke rendering at the end of each stroke when drawing on an empty canvas with 2 or more empty/hidden layers in stack and Image background opacity set to 0%. Painting on a single empty layer in stack and 0% Image BG opacity will not cause issue. Setting Image BG opacity to 0,05-100% or having filled paint layer or Fill Layer underneath with at least 1% opacity will also result in normal stroke performance. EXPECTED RESULT No performance issues when drawing on an empty canvas with 2 or more layers in stack. SOFTWARE/OS VERSIONS Windows: Windows 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.15.7 ADDITIONAL INFORMATION Tested on all three Canvas Graphics Acceleration options and without (CPU rendering) all with same results, so it doesn't seem to be an issue with OpenGL renderer. No difference in CPU and RAM usage between normal and abnormal performance. Important to note: Attempting to reproduce this bug on very small canvas will not show any significant performance drop and bug won't be apparent. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464871] Dynamic Brush Tool, Smoothing Problem (but not need restart)
https://bugs.kde.org/show_bug.cgi?id=464871 Dorijan Salak changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||dorijan.sa...@gmail.com Ever confirmed|0 |1 --- Comment #1 from Dorijan Salak --- I can confirm that indeed the Freehand Brush Tool's Smoothing settings somehow affect Dynamic Brush Tool. I've observed two different issues and have some extra info to share on this, in case it might be useful. If Freehand Brush smoothing is set to None, Basic, Weighted or Stabilizer (any amount) and Dynamic Brush Mass set to 0 prior to closing document or Krita, upon re-opening document (where Freehand sets as default even if dynamic was used) and then changing to Dynamic Brush its Mass (Smoothing) will be broken as if Mass is set to 100. Changing Mass from 0 up by any amount will reset it and will work as intended, even at 0 again. In case where Freehand Brush was set to None and Dynamic Brush Mass set to any amount, upon closing > opening a document not only will it break Mass (if it was set to 0) again but also completely change Dynamic Brush algorithm to Freehand - None where drawn curved lines will be made of snappy straight lines (most noticeable when drawing curve (circle for example) zoomed far out), which doesn't normally happen with Dynamic Brush. In this case only changing Freehand to anything but None and Dynamic's Mass to 0,01 or above then rebooting Krita will reset Dynamic Brush tool back to normal behavior (I suppose, as I'm not certain if it ever truly works as intended). Dynamic Brush Drag option doesn't seem to be affected in any way. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 476776] Performance drop with In-stack preview for Transform Tool
https://bugs.kde.org/show_bug.cgi?id=476776 --- Comment #3 from Dorijan Salak --- (In reply to Dmitry Kazakov from comment #1) > Hi, Dorijan! > > Could you please make a screen recording of the issue? I cannot reproduce it > here locally :( > > Can it be that you change the zoom level of the document in between the > transformations? It could result in a different level-of-detail of the image > to be used for preview, which could result in a different speed... Hi, Dmitry! As requested, I've uploaded screen recording to attachment. Not sure why it cannot be reproduced on your side nor why is it happening on my side but I know I can reproduce this 100% of the time and definitely doesn't look like a normal behavior especially because performance returns back to normal if I add new layer or delete existing one (as can be seen in recording). In case it might be useful info, specs: - CPU Intel i7 7700k - GPU Nvidia RTX 2080 Super - RAM DDR4 32GB 3000MHz - Storage Samsung 960 EVO 500GB NVMe For Krita settings I've tested with (both OpenGL and ANGLE) and without Canvas Acceleration, let Krita use all available cores and up to 24GB of RAM which is never even closely used. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 476776] Performance drop with In-stack preview for Transform Tool
https://bugs.kde.org/show_bug.cgi?id=476776 --- Comment #2 from Dorijan Salak --- Created attachment 163487 --> https://bugs.kde.org/attachment.cgi?id=163487=edit Performance drop issue with transform tool Happens with Accurate and Accurate with Instant Preview methods but not with Fast method. No noticeable performance drops if transformed content is only a small portion of the canvas size, has to be larger as shown in the screen recording. My movement speed both before transform and after are unchanged/similar as seen by the speed of cursor, but the content lags behind after transform (slight rotation in this case but anything causes performance drop). Adding new layer to the layer stack or deleting existing resets performance back to normal. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 476776] New: Performance drop with In-stack preview for Transform Tool
https://bugs.kde.org/show_bug.cgi?id=476776 Bug ID: 476776 Summary: Performance drop with In-stack preview for Transform Tool Classification: Applications Product: krita Version: 5.2.1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: dorijan.sa...@gmail.com Target Milestone: --- SUMMARY Performance for Free Transform moving/transforming drops after transforming selected layer. Creating new layer or deleting any layer in the stack will reset performance back up to max for previously transformed layer. STEPS TO REPRODUCE With In-stack preview mode for transform tool (with or without instant preview): 1. Create new document or open any image, something larger (I've tested on A4 300ppi size or larger), not as noticeable on small sizes 2. Fill layer with something - fill entire layer with color/bucket, add rectangle, circle or whatever (again make it larger, not small circle/rectangle in center) or select existing image on layer in case of opening image 3. Select layer with Free Transform tool and attempt to move it around, performance will be fine at first, then resize, rotate or something (don't resize too small or it won't be noticeable as much) and apply transform. 4. Attempt to move it around again and performance will be much lower; slow movement, slow resizing, rotating etc. 5. Create a new layer or delete another existing layer (keep the one we're testing at) 6. Switch back to the layer that was transformed and had low performance, now the performance will be back to normal Can be reproduced 100% of the time with same result. OBSERVED RESULT Performance drops after transforming selected layer then goes back to normal when adding/removing another layer from the stack. EXPECTED RESULT No performance drops after transforming a layer. SOFTWARE/OS VERSIONS Windows: Windows 10 Pro Qt Version: 5.15.7 Krita Version: 5.2.1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 476571] Creating Filter Layer based off current selection then changing its Blending mode will produce artifacts and weird behavior
https://bugs.kde.org/show_bug.cgi?id=476571 --- Comment #2 from Dorijan Salak --- I see, so that's the duplicated layer basically and transparency mask doesn't automatically apply for the selection but rather only for what the filter changes. Thank you for the explanation. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 476571] New: Creating Filter Layer based off current selection then changing its Blending mode will produce artifacts and weird behavior
https://bugs.kde.org/show_bug.cgi?id=476571 Bug ID: 476571 Summary: Creating Filter Layer based off current selection then changing its Blending mode will produce artifacts and weird behavior Classification: Applications Product: krita Version: 5.2.1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: dorijan.sa...@gmail.com Target Milestone: --- Created attachment 162874 --> https://bugs.kde.org/attachment.cgi?id=162874=edit Results - Initial Filter Layer effect vs Changing blending mode vs Workaround SUMMARY Not certain if this is a bug or a limited functionality of how Filter Layer's transparency (alpha) works in Krita but the results are weird and could be caused by a bug. If Filter Layer is added while having an active selection (in order to affect only selected area) then changing its Blending Mode (for example from default Copy to Overlay) creates box artifact around affected area and further if turning visibility of affected layers (layers below the added filter layer) the effect spreads to entire affected layers. STEPS TO REPRODUCE 1. Create Paint Layer and draw something (rectangle for example) with any color except pure white or black (as the result may not be visible based on used blend mode) 2. Create a selection selecting a portion of added pixels on paint layer (portion of the rectangle) 3. Add Filter Layer (Gradient Map, HSV adjustment or literally any filter) 4. Change Filter Layer Blending Mode from default Copy to Overlay or something (some may have a visible issue based on colors used) OBSERVED RESULT After Changing the Blending Mode of created Filter Layer, the alpha(?) of that Filter Layer (not entire added filter effect) will spread around initially affected selection in a box shape and further turning visibility of affected Layer/layers below will spread the effect to entire affected layer (the rectangle from example). EXPECTED RESULT After Changing the Blending Mode of created Filter Layer, only Blending Mode within initially affected Selection should change. SOFTWARE/OS VERSIONS Windows: Windows 10 Pro, Version 2009 KDE Plasma Version: nowhere to be found within Krita Help > About KDE KDE Frameworks Version: same as above Qt Version: 5.15.7 ADDITIONAL INFORMATION Currently Installed Krita version 5.2.1 but the issue seems to go further back (tried 5.0 up to 5.2.1 and had same results). Used RGB/Alpha 8-bit Color Space, but results are the same in other Models/Depths too. WORKAROUND Only way I could find where alpha of Filter Layer doesn't partially bleed past selection is to Add Transparency Mask based on said selection to the Filter Layer after changing blending mode. This produces close to desired result where changing blending mode will stick to selection (currently transparency mask). However if the transparency mask is added before changing from copy to another Blend will again reproduce only partial bleed where in order to get full change I have to turn visibility of affected layer off/on, same if I go back to copy from any other blending mode. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475587] Random noise filter issues
https://bugs.kde.org/show_bug.cgi?id=475587 --- Comment #3 from Dorijan Salak --- Been fiddling around with filters in general and I found out more bugs that are probably closely tied to this report. Unsure if I should fill a new report or add more info here but for now I'll just add here some of the issues I found out. Generally adding filters through Krita > Filter menu (or their corresponding shortcuts) will have a weird behavior. Some filters don't show updated preview on canvas or when applied destructively (OK button in the called menu) will not apply at all (as if no change was made to curves and such). While when applying same filter as mask (Create Filter Mask button in the same menu) will show changes on the canvas but only after creating the mask, not in preview, and later further adjusting (F3 on added filter) will work as it should showing correct preview and everything. Some filters have issues only when applied to certain layer type, such as filtering a Filter Layer or Fill Layer while they work correctly on Paint Layer (ex. Color Adjustment will work on Paint Layer correctly but not on Filter or Fill Layer while Random Noise seems to be incorrect on most layer types). Many, if not all, filters have similar issues when added this way but when added through Layers widget (+ sign on the bottom or settings drop down then add > filter mask or their corresponding shortcuts) will work correctly. Random noise still seems to have an issue if changing parent layer opacity no matter which way the filter is added. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475591] There's some malfunctions in 'Opacity' option for masked brush
https://bugs.kde.org/show_bug.cgi?id=475591 Dorijan Salak changed: What|Removed |Added CC||dorijan.sa...@gmail.com --- Comment #2 from Dorijan Salak --- I would like to add that Masked Brush - Flow option is also confusing in a same way with the new checkbox even though the strength does work as it should. No matter if turned on or off the curve and strength in effect is as set by user. As Freya mentioned, it is probably best to treat it as 100% with default curve if checkbox is off for both opacity and flow in masked brush section. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475587] Random noise filter issues
https://bugs.kde.org/show_bug.cgi?id=475587 --- Comment #2 from Dorijan Salak --- (In reply to wolthera from comment #1) > I can only reproduce the 'destructive' version, but not the filter mask > version, but reproduce I can. Hmm, weird... I can reproduce it every time both ways. But when applied as mask only when I add extra pixels or change layer opacity/blending mode. Also found out if I turn off the parent layer, the noise from the random noise mask stays active everywhere except for the box shape around where parent layer pixels were. -- You are receiving this mail because: You are watching all bug changes.
