Bug 436422

Summary: Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
Product: [Applications] krita Reporter: Autumn Lansing <autumn>
Component: Tool/AssistantsAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: ahab.greybeard, ghevan, info, rafael.linux.user, tamtamy.tymona
Priority: NOR    
Version: 4.4.3   
Target Milestone: ---   
Platform: Appimage   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Video showing bug with concentric ellipse tool
Concentric Circle Assistant Circles
Image of Krita assistant tool bug
Guide
Strokes using guide
KRA used

Description Autumn Lansing 2021-04-30 19:45:35 UTC
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
Comment 1 Ahab Greybeard 2021-05-01 22:25:00 UTC
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?
Comment 2 Autumn Lansing 2021-05-02 03:48:33 UTC
I use an Intuos 4. And it happens with both tablet and mouse. It also happens with each brush smoothing option.
Comment 3 Ahab Greybeard 2021-05-02 11:42:24 UTC
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?
Comment 4 Autumn Lansing 2021-05-02 20:48:53 UTC
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.
Comment 5 Autumn Lansing 2021-05-03 21:11:20 UTC
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.
Comment 6 Tiar 2021-08-19 20:41:40 UTC
Yes, it's the assistant tool design flaw :(
Comment 7 Ahab Greybeard 2021-08-19 22:56:03 UTC
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.
Comment 8 Autumn Lansing 2021-08-24 21:05:31 UTC
Created attachment 141019 [details]
Image of Krita assistant tool bug
Comment 9 Autumn Lansing 2021-08-24 21:06:01 UTC
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.
Comment 10 Ahab Greybeard 2021-08-25 10:14:25 UTC
@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.
Comment 11 Ahab Greybeard 2021-08-25 12:40:26 UTC
@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.
Comment 12 Autumn Lansing 2021-08-25 21:14:07 UTC
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.
Comment 13 Ahab Greybeard 2021-08-26 09:01:00 UTC
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.
Comment 14 Ahab Greybeard 2021-08-26 09:04:40 UTC
*** Bug 440108 has been marked as a duplicate of this bug. ***
Comment 15 Ralek Kolemios 2021-08-26 17:58:54 UTC
(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.
Comment 16 Rafael Linux User 2023-09-05 12:26:28 UTC
I was creating an issue about it. I attach screenshots and the ".kra" example.
Comment 17 Rafael Linux User 2023-09-05 12:27:47 UTC
Created attachment 161413 [details]
Guide
Comment 18 Rafael Linux User 2023-09-05 12:28:22 UTC
Created attachment 161414 [details]
Strokes using guide
Comment 19 Rafael Linux User 2023-09-05 12:28:57 UTC
Created attachment 161415 [details]
KRA used
Comment 20 vanyossi 2023-09-07 21:09:40 UTC
(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.
Comment 21 Rafael Linux User 2023-09-08 12:07:48 UTC
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.
Comment 22 Dmitry Kazakov 2023-09-08 15:14:55 UTC
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
Comment 23 Dmitry Kazakov 2023-09-08 15:15:57 UTC
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