Created attachment 138036 [details] Video showing bug with concentric ellipse tool SUMMARY The concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants." When you begin the stroke, the pen travels a short distance before anything appears on the canvas, and when the stroke does appear it jumps from the point where you first put down the pen to the point where the pen currently sits, creating a straight line. Continuing the stroke happens in a perfect circle until you reach a point near the end of the circle, and then it again stops and makes another straight line jump to the point where the circle first began. The two straight line jumps are equal in length. STEPS TO REPRODUCE 1. Create a concentric ellipse with the assistant tool. 2. Draw a circle with "snap to assistants." OBSERVED RESULT The stroke jumps in a straight line at the beginning and at the end of the circle. EXPECTED RESULT A perfect circle without any straight lines. Krita Version: 4.4.3 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.10.21-200.fc33.x86_64 Pretty Productname: Fedora 33 (Cinnamon) Product Type: fedora Product Version: 33 Desktop: X-Cinnamon OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 660/PCIe/SSE2" Version: "4.6.0 NVIDIA 460.56" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 24034 Mb Number of Cores: 4 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: DVI-D-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: HP Inc. Model: HP VH240a- Refresh Rate: 60 Screen: 1 Name: DP-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: LG Electronics Model: LG IPS FULLHD Refresh Rate: 60
I don't see that happening with the 4.4.3 appimage on Debian 10 when using the mouse or a Wacom graphics tablet. Does it happen when you use a mouse? Which graphics tablet do you have? Is Brush Smoothing set to None?
I use an Intuos 4. And it happens with both tablet and mouse. It also happens with each brush smoothing option.
A drawn curve starting with a 'jump' giving a straight line segment has been seen before with freehand curves in some situations, due to tablet settings I think. Do you get that if you draw a freehand curve?
As it happens with a mouse and even with my tablet unplugged, it's probably not related to tablet settings. I've previously reported the so-far unaddressed bug 434269, which can sometimes cause freehand curves to jump and give a straight line, but in that case it only happens if I don't wait the three seconds or so for the freeze to happen before starting my stroke. If I wait until after the brief freeze, then I can draw a freehand curve without any problems. In this new bug, there is no freeze. It happens whenever I draw a circle /ellipse with the tool, regardless. It's mostly unnoticeable at large scale, but when drawing small circles, it's highly noticeable. The smaller the circle, the more noticeable it is.
And I noticed today that this happens with ALL the assistant tools. It's just not as easily noticeable when making a straight line. There is a jump in each tool at the start, which results in a slightly darker line segment than the rest of the stroke.
Yes, it's the assistant tool design flaw :(
Created attachment 140861 [details] Concentric Circle Assistant Circles There is a small start up delay when snapping to an assistant line but it's about 3 or 4 pixels and I don't get the large straight lines seen in Autumn's example. I've attached a screenshot from 4.4.7 using a 2px brush with small circles as you can see by the pixel grid being visible. Each circle was started at the 45 degrees position.
Created attachment 141019 [details] Image of Krita assistant tool bug
Ahab, the bug can be very hard to see the larger the circle you make. Even I wouldn't notice it at the size you show in your image if I wasn't looking for it. Try zooming in and making a very tiny circle that's about one grid wide. It's very visible at that scale. Likewise, the related problem with straight lines is about 1/2 pixel in width.
@Autumn: The grid you see in the image I posted is the 1-pixel grid and I'm already drawing smaller circles than you showed in your example. I can see and count the pixels in your images. This is caused by the 'start jump/delay' when snapping to assistants. For me, the start jump/delay is 3 pixels and that is the same for concentric circles and the parallel ruler. For you, it looks like it's about 12 pixels on the circle and I'm surprised that it's smaller for a straight line. I've started a topic at: https://krita-artists.org/t/request-for-simple-test-feedback-of-snap-to-assistants/28018 asking other people to test and report what it is for them because this may have variation for reasons that I've no idea about.
@Autumn: With reference to this topic: https://krita-artists.org/t/call-for-testing-2-point-perspective-assistant/21751 Please try again with a document that has a resolution of 1 dpi. I think that will give you a good workaround.
I'm assuming that dpi and ppi are the same thing? The jump/delay doesn't happen at 1 ppi. To be honest, I don't consider that a tenable workaround, at least not for me at the scale I work. My usual page size is 2008 x 3071 pixels at 300 ppi. Testing out conversion back and forth between 300 and 1 ppi, I've yet to successfully finish. Each time I try, the "Updating" bar at the bottom never moves from 0%, even after ten minutes, and I've had to kill Krita each time because it becomes unresponsive. It's far less of a hassle to deal with the jump/delay than trying to convert existing documents and templates between the two ppis and hoping it works. Or perhaps I'm just not doing it right.
This happens because the snapping action needs some distance to be travelled by the cursor to confirm snapping (which is important when there is more that one possible assistant guide line to snap to). This distance is affected by the Resolution (ppi) of the image and so it seems to use the 'physical' distance and not image pixel distance or maybe screen pixels travel distance. Setting to Confirmed.
*** Bug 440108 has been marked as a duplicate of this bug. ***
(In reply to Ahab Greybeard from comment #14) > *** Bug 440108 has been marked as a duplicate of this bug. *** > Having to move 200 pixels is excessive but this has been seen before. > It may be that you have a large ppi setting for your image. > > *** This bug has been marked as a duplicate of bug 436422 *** This was it, I was showing a friend what PPI meant a long time ago and set it to 1 for an example. I forgot to change it back or neglected to since I figured it didn't affect anything other than print settings and metadata. +1 for making the distance snapping related to something other than relative real world distance.
I was creating an issue about it. I attach screenshots and the ".kra" example.
Created attachment 161413 [details] Guide
Created attachment 161414 [details] Strokes using guide
Created attachment 161415 [details] KRA used
(In reply to Rafael Linux User from comment #18) > Created attachment 161414 [details] > Strokes using guide This issue is not related, the way your ellipses look it appears you have set assistants magnetism below 1000. To summarize the original bug: The original issue still happens in krita master (42494a3d36). To easily trigger: - set image dpi to a high number: 3200dpi - use an assistant with concentric/parallel options and set it with a curve. (concentric ellipse set as a circle will work) - paint with snap to assistant active.
Hello again I attached the KRA file thinking that the values of the tools would be preserved, but from what you answer I understand that this is not the case, because you mention the magnetism of the assistant and the truth is that I have kept the default value (1000, which is the maximum). However, thanks to your comment I have found out something more interesting about the problem: it depends on the zoom level applied!!!! When I start the trace with a zoom level far away, the ellipse trace is not correct (as seen in the images). However, if I zoom in and start the same trace, an ellipse is drawn perfectly, without anomalies. Please check it yourself with my example file.
Git commit 0a0bc253b238594c25875d6a5f83a493bac25af9 by Dmitry Kazakov. Committed on 08/09/2023 at 17:14. Pushed by dkazakov into branch 'krita/5.2'. Fix artifacts when using assistants in images with high DPI The start-stroke-threshold should be measured in screen-px, not in pt, which might be quite big in hires images. M +3 -1 libs/ui/kis_painting_assistant.h M +11 -4 libs/ui/kis_painting_assistants_decoration.cpp M +3 -3 libs/ui/tests/kis_painting_assistants_decoration_test.cpp M +5 -7 plugins/assistants/Assistants/ConcentricEllipseAssistant.cc M +2 -2 plugins/assistants/Assistants/ConcentricEllipseAssistant.h M +1 -1 plugins/assistants/Assistants/EllipseAssistant.cc M +1 -1 plugins/assistants/Assistants/EllipseAssistant.h M +4 -7 plugins/assistants/Assistants/FisheyePointAssistant.cc M +2 -2 plugins/assistants/Assistants/FisheyePointAssistant.h M +6 -6 plugins/assistants/Assistants/InfiniteRulerAssistant.cc M +2 -2 plugins/assistants/Assistants/InfiniteRulerAssistant.h M +5 -5 plugins/assistants/Assistants/ParallelRulerAssistant.cc M +2 -2 plugins/assistants/Assistants/ParallelRulerAssistant.h M +5 -9 plugins/assistants/Assistants/PerspectiveAssistant.cc M +2 -2 plugins/assistants/Assistants/PerspectiveAssistant.h M +1 -1 plugins/assistants/Assistants/PerspectiveEllipseAssistant.cc M +1 -1 plugins/assistants/Assistants/PerspectiveEllipseAssistant.h M +1 -1 plugins/assistants/Assistants/RulerAssistant.cc M +1 -1 plugins/assistants/Assistants/RulerAssistant.h M +1 -1 plugins/assistants/Assistants/SplineAssistant.cc M +1 -1 plugins/assistants/Assistants/SplineAssistant.h M +1 -1 plugins/assistants/Assistants/TwoPointAssistant.cc M +1 -1 plugins/assistants/Assistants/TwoPointAssistant.h M +5 -5 plugins/assistants/Assistants/VanishingPointAssistant.cc M +2 -2 plugins/assistants/Assistants/VanishingPointAssistant.h https://invent.kde.org/graphics/krita/-/commit/0a0bc253b238594c25875d6a5f83a493bac25af9
Git commit 98b0868395bc523251fc7a3f1970f279224555a9 by Dmitry Kazakov. Committed on 08/09/2023 at 17:15. Pushed by dkazakov into branch 'master'. Fix artifacts when using assistants in images with high DPI The start-stroke-threshold should be measured in screen-px, not in pt, which might be quite big in hires images. M +3 -1 libs/ui/kis_painting_assistant.h M +11 -4 libs/ui/kis_painting_assistants_decoration.cpp M +3 -3 libs/ui/tests/kis_painting_assistants_decoration_test.cpp M +5 -7 plugins/assistants/Assistants/ConcentricEllipseAssistant.cc M +2 -2 plugins/assistants/Assistants/ConcentricEllipseAssistant.h M +1 -1 plugins/assistants/Assistants/EllipseAssistant.cc M +1 -1 plugins/assistants/Assistants/EllipseAssistant.h M +4 -7 plugins/assistants/Assistants/FisheyePointAssistant.cc M +2 -2 plugins/assistants/Assistants/FisheyePointAssistant.h M +6 -6 plugins/assistants/Assistants/InfiniteRulerAssistant.cc M +2 -2 plugins/assistants/Assistants/InfiniteRulerAssistant.h M +5 -5 plugins/assistants/Assistants/ParallelRulerAssistant.cc M +2 -2 plugins/assistants/Assistants/ParallelRulerAssistant.h M +5 -9 plugins/assistants/Assistants/PerspectiveAssistant.cc M +2 -2 plugins/assistants/Assistants/PerspectiveAssistant.h M +1 -1 plugins/assistants/Assistants/PerspectiveEllipseAssistant.cc M +1 -1 plugins/assistants/Assistants/PerspectiveEllipseAssistant.h M +1 -1 plugins/assistants/Assistants/RulerAssistant.cc M +1 -1 plugins/assistants/Assistants/RulerAssistant.h M +1 -1 plugins/assistants/Assistants/SplineAssistant.cc M +1 -1 plugins/assistants/Assistants/SplineAssistant.h M +1 -1 plugins/assistants/Assistants/TwoPointAssistant.cc M +1 -1 plugins/assistants/Assistants/TwoPointAssistant.h M +5 -5 plugins/assistants/Assistants/VanishingPointAssistant.cc M +2 -2 plugins/assistants/Assistants/VanishingPointAssistant.h https://invent.kde.org/graphics/krita/-/commit/98b0868395bc523251fc7a3f1970f279224555a9