I am trying to understand using radians to draw an arc, but it seems backwards.
This code is drawing a quarter circle twice, but although the direction is set to True (clockwise) they seem to always draw anti-clockwise. Can someone please explain for me?
In this example, I expected 2 x quarters, bottom right but I got 2 x three quarters, exactly the opposite.
// xojo sample
Const Pi = 3.14159
Var arc As New GraphicsPath
arc.AddArc(50, 50, 20, 0, Pi / 2, True)
g.DrawPath(arc)
arc.AddArc(150, 150, 20, 0, Pi / 2, True)
g.DrawPath(arc)
After some testing, I think the “joining” line that is supposed to go from the end of the first arc to the start of the second one is wrong. It seems to go from the wrong ends of the arcs.
Can someone please confirm?
This is the first time I play with AddArc so I read the docs here: https://documentation.xojo.com/api/graphics/graphicspath.html#graphicspath-addarc
So I read this:
clockwise A Boolean value that specifies whether or not to draw the arc in the clockwise direction.
What I understand is that if we set that as True then the arc should start at X and down but in this case we get that with False.
I expected to only have a 90 degree arc one way or the other right/down with True and right/up with False, but we get 90 degree right/down with False and 270 degree arc right/up with True.
So, to get a 90 degree arc from right/up I need this code:
arc.AddArc(50, 50, 20, 0, Pi * 1.5, True)
instead of
arc.AddArc(50, 50, 20, 0, Pi / 2, False)
that is what I expected by reading the docs. I expected the same as you Phil.
Note: strange that the forum put different colors on the pasted code.
So it’s not just me being crazy… I put 2 curves so I could see the line joining the two, the documentation says it should go from the end of the first to the beginning of the second one.
Looks like a bug, hopefully someone knowledgeable will confirm or deny that. Thanks for looking.
Well, the line connecting both curves is “correct” in the sense that it is connecting the endpoint of the first arc to the first point of the second arc, this is to illustrate start the arc in 1, end in 2, connect with 3 and end in 4
Yes, that’s right. The line is going from ‘end’ to ‘start’.
The only problem is that the clockwise/anticlockwise is wrong. That diagram of yours is what we see when we put “True” but the curves are anticlockwise.
Although I think anyone would interpret the documentation the way you did, actually it doesn’t specify which value of the boolean property is the one giving you a clockwise drawing direction. At the very least I think the documentation should be improved, but in my opinion this is a bug, I am not saying it is not.
However, I am used to working with the Y axis pointing upwards so I thought maybe inverting that axis would shed some light on the matter and this is what I got:
The rotation direction makes sense if we invert the vertical axis… I don’t know if that’s the reason for the current behavior, or it’s a bug, as said before.
Thanks Julen, I am not sure which way your curves are being drawn, and I don’t really want to invert my axis.
The specs I screenshotted are for GraphicsPath.Addarc and they have more info than some other arc-related docs… Stating that the boolean value is relating to clockwise if True.
But it is ambiguous, because I noticed that switching start and end values implies a direction also, since the positive values go opposite directions depending on the y value. It’s all very confusing for a novice, but I think the true/false is redundant except to use as a patch for when the other values don’t work for me!
What I am really wanting to achieve is control over the linking line between 2 arcs as per my example and what I am getting doesn’t match the docs in my opinion.
PS, I think what is throwing me is the phrase “measured from the X axis”, which I don’t really understand right now, but I think that what it is implying is that below the centre, the scheme flips?
Of course, I just inverted the Y axis because things make more sense to me that way and to try to undestand the logic behind the current behavior. I just flipped the Y axis and adapted the code in the second canvas to the new reference system.
Those are the six values you can change in my test project.
That’s what I would understand too, but the phrasing of the explanation for the boolean parameter is slightly ambiguous in my opinion, and one could argue that it doesn’t say what the actual drawing direction is for each value of the parameter. Also, clockwise or counterclockwise is a matter of point of view. If you look at your canvas along the +Z direction (as Xojo does) you get a direction, but if you look at it along the -Z direction (as it is more commonly done in many other fields) you get the other rotation direction.
In your case, as a workaround I would simply invert the boolean parameter. Doens’t that give you the result you expect?
I would also file a bug report because there is a bug/an issue either with the implementation of the method or the documentation.
All screen coordinates have 0,0 at the top lefthand point on the screen or window or object. This is not only true in Xojo, all HTML is the same.
And although the doc for the clockwise paramter should be much more explicit, one might easily infer that if clockwise is true, that will be the drawing direction.
I believe this is a reply to my previous sentence stating that in other fields it is more common to use a different orientation for the Y axis, note that I wrote “fields”, I wasn’t talking about other programming languages.
Yes, I’m well aware of what happens in other fields. I’m just pointing out that all screen-drawing software works this way, and it’s not a bug. See also Graphics — Xojo documentation which explicitly mentions the coordinate system - which is also used in the IDE when laying out objects.
By the way, thanks for pointing this out since I searched for it and couldn’t find it. It would be nice if the reference system for the angle could be added there (I would submit a FR but I don’t have FB installed).
Yes - and also that coordinate system info could be added to the graphicspath, canvas, and window pages so that it’s more noticeable. I was lucky in that my development was on HTML/javascript before I moved to Xojo.
BTW, every Xojo docs page has a link for docs feedback at the bottom.
