Centering circle and arc draw elements

Yep, I had the same problem. The solution is to draw four circles, each of which is centered around one of the 4 "center pixels" in the screen. :/

It still doesn't look exactly like whatever native code is doing to draw "perfect" arcs/circles, but it's better than nothing.

forums.garmin.com/.../dc-drawcircle-inside-screen-edge-even-numbered-screen-height-width

Yeah, I have been able to get away with it for the most part, but it required a lot of offset fiddling to get everything to look just right. More recently, I added an inner triangle to a sweeping dial (sweeping around the outer radius) and it is noticeably shorter when sweeping around the bottom than the top (getting clipped by the inner circle)... There are some things I could try to further mitigate but just wanted to make sure I was not overlooking a simpler option. :)

To give more context, I have a function that takes any polygon and calculates its position as it sweeps around a radius, so its always pointed toward the face edge. I think my current issue is a combination of slight offsets with the radius center coupled with polygon coordinates rounding to the nearest pixel. The solution may be to have x/y offsets based on the sweep angle. 

I wouldn't do 4 circles (4 draws vs 1 - think battery) but may tweak the radius and pen width so it looks good, and I'd judge it on a device vs the sim as the sim exaggerates the size of a pixel.

I guess the battery would also be an issue if I were to attempt 4 arcs -- each with a relative offset to compensate for the even pixel division? :)

jim_m_58 said:

I'd judge it on a device vs the sim as the sim exaggerates the size of a pixel.

As I said in the linked thread from over 2 years ago, I can tell on both the simulator and the device. I agree that the result on the device is what matters, though.

I can also tell that the native 935 firmware code which draws the GPS ring does not have this problem.

For what it's worth, the 4-circle approach is also what Brian.ConnectIQ described as "the best workaround that is perfectly symmetrical".

I didn't claim it was good for battery life -- I'm only saying this is the best known solution. The thread has another idea, such as using a font scaled to your screen size, but I think this is the simplest and most flexible solution.

I appreciate the all the feedback. In my case I am drawing a number of circles, arcs, lines and polygons around a common radius value. I would be happy with the center offset if the relative positioning of all elements held but that is not the case for me. The issue is the relative positioning of polygons which is not consistent around the center circle as they sweep around it.

I will need to take a closer at my code but I think the issue is I am not rounding my point values as I calculate the sweep angle for the polygon. Per Jim's description, the x,y values are floor'ed (vs. rounded) which would explain why relative positions of the polygons are off between 12 o'clock and 6 o'clock positions. 

Otherwise, I was really hoping there was support for x,y float values as I am working with drawn graphics with finer details that become slightly distorted as the elements are rotated across a radius. 

Btw, are the new 4.0 APIs documented? I cannot find anything linked from the announcement but I did see something about SVG support. Perhaps this will unlock a finer grain of plotting detail? 

In your case, maybe you could have a 2x2 center square (as opposed to a point) and calculate all your offsets from that, since you already have a custom draw function.

EDIT: Also, sorry for the irrelevant initial response haha.

Retsof81 said:

Btw, are the new 4.0 APIs documented? I cannot find anything linked from the announcement but I did see something about SVG support. Perhaps this will unlock a finer grain of plotting detail? 

In the SDK itself there are documents like the API guide and a few others that go into the new features.  Right now, it's only a preview, so you can't do things like build an iq file.  There's also the sample watchface that shows monkey types, and in it, you can see the scaling and how it uses svg files,

FlowState said:

Also, sorry for the irrelevant initial response haha.

No worries. :) 

Yeah, I think my final solution will require me to map different center coordinates for various sweep angles, making +/- radius adjustments as the polygon sweeps across each WF quadrant. 

In the end, this is all for something that only a few ppl will actually notice, but I rarely get to code for UX (particularly a WF), so I am enjoying the effort. :)