death.crafter wrote: ↑June 1st, 2021, 4:46 pm
I tried it and found out it is the stroke width at the point of conjunction of the two arcs. [...] The more the stroke width, the more the height of the redundant line. And this problem persists even if you use two different shapes and combine them wit XOR.
So I guess it's a bug in the StrokeWidth
of arcs(or path) when the junction point is intersecting each other at an acute angle.
balala wrote: ↑June 1st, 2021, 5:29 pm
If you do, this indeed is better, however not perfect. Let's see if this is indeed a bug. Waiting for a dev, to tell what's going on.
Well, I'm not a developer (at least not of Rainmeter), but this is definitely a bug. Death.Crafter is correct, the bug gets worse if one increases the StrokeWidth parameter, but the underlying cause of this is not the StrokeWidth, but rather the SweepDirection parameter of Arc shapes
when its value is 1. Before I enter into other details on the matter, here's a temporary workaround, but only
for low StrokeWidth cases:
Code: Select all
Shape=Path MyPath | StrokeWidth 2 | Stroke Color 0,0,0 | Fill Color 255,255,255
MyPath=10,65 | ArcTo 130,65,60,20,0,1,0 | LineTo 130,65 | ArcTo 10,65,60,80,0,0,0
It's basically about using a LineTo segment to the same 1st arc ending to "stabilize" the incorrect line segment problem.
This won't work completely for higher StrokeWidth-s though. Though it mostly corrects the original code behavior (i.e. without the "static" LineTo segment), setting StrokeWidth to 10 in the above code still produces similar (but milder) artefacts:
Changing the "static" LineTo end point coordinates (like setting its Y to, say, 68) to try and further correct the issue actually makes it even worse (and in the wrong direction, LOL):
However, when changing the SweepDirection parameter of the 1st ArcTo segment to the default 0 (that segment would then become ArcTo 130,65,60,20,0,0,0
), it seems the following arc (i.e. the 2nd one) correctly grabs its starting point, even without the static / stabilizing LineTo segment:
So it looks to me that the behavor is triggered by the SweepDirection parameter of an ArcTo, and its effects are grossly made worse by a higher StrokeWidth. Maybe it has something to do with how those intersecting ellipses that an arc is made of create the shape in the first place - the intersection point when the ellipses are not partially exclusive could be "lost" somehow...
You do not have the required permissions to view the files attached to this post.