Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Fractional "start-angle" and "sweep-angle" for arcs in GUI (SVG) files

Greetings all!

 

I've really been enjoying the Fitbit SDK, but have come up against and issue that is a bit frustrating!

 

It is not currently possible to specify fractional values for svg elements (either in the SVG or via JavaScript). Normally, this is not a big deal (drawing a straight line between two points only really makes sense when it aligns with the pixel grid); but that is not the case with angular units, such as for 'start-angle' and 'sweep-angle' for arc elements (whereby, especially for large circles, a single degree corresponds to a movement of 10s or 100s of pixels).

 

Is it possible to work around this? Or for this feature to be added to the platform?

 

Best,
M

Best Answer
0 Votes
5 REPLIES 5

You can't have fractional values, I assume, because that would take up memory. However, it automatically rounds it to the nearest number. You can try to get a decimal value in there by using the Math.round() function, but I don't really see why it's necessary to have fractions and decimals in a watch app/face.

Best Answer
0 Votes

One hack for this in robotics, and I assume it would work here is to change your units through a multiplier and in effect changing the resolution.  Lets say you are plotting something on a 100 pt. scale, but converting it to degrees.  It could be probable that x% as an integer would equate to y.z float value in degrees X/360.  However, if you took x% and multiplied it by 36, then if your input is an integer, so then should your output.  

To get even more resolution out of your integers, you could multiply both pieces of the ratio.  You could figure out the relationship between the degrees and pixels then multiply your input by 36 then by the ratio between pixels and degrees.  We do this with encoders frequently because encoder ticks are float values, but not all encoders have the resolution we want.  So, we need to change the resolution to match. Like with the encoder trick, we are not creating data that does not exist.  We are just upscaling (or downscaling) it.  If your input is a base 10 integer, and your output is a base 360, multiplying the input by 36 and then plotting it is not going to to put an input of  7.6666666666 (or pi for that matter) the perfect place, however, if the input was a float, it should come close. The same is true with robotics (and actually tvs, that is sort of one they convert 1080 to 4k, of course then they also add an algorithm layer to make up for lost data).  You cannot make a 4 counts per revolution encoder have the accuracy of one with 4000 CPR, but you can get integers you can work with.  

Having said all of this, many times rounding can be just as effective and save some work by both you and the processor.  For those situations in which it matters, this could be a workaround.

 

I hope this makes sense and helps a bit.

P.S. I am making numbers up, so I apologize if my math is wrong.  I tend to have to go through a few iterations to find the correct multiplier.

Best Answer
0 Votes

@MadderHatter wrote:

Greetings all!

 

I've really been enjoying the Fitbit SDK, but have come up against and issue that is a bit frustrating!

 

It is not currently possible to specify fractional values for svg elements (either in the SVG or via JavaScript)...

 

Best,
M


Hello M,

 

I think the integral limit on the resolution of angles is most annoying when trying to butt the end of one arc against the start of another.

 

The work-around I used was to make the arcs overlap so the one in front can start pretty close to the angle I want without exposing a gap between the two.

<arc id="Arc1" fill="green" sweep-angle="49" start-angle="0" />
<arc id="Arc2" fill="limegreen" sweep-angle="94" start-angle="47" />

Regards,

Best Answer
0 Votes

Hi LekoFraggle! Thanks for your suggestion about rescaling. That is a neat trick in many places (to increase the resolution by increasing the cardinality of possible values using multipliers/etc); but unfortunately here the limitation is a rendering one (and we don't control the rendering resolution / etc). It's hard-coded into the system.

Best Answer
0 Votes

Aye... thanks for your contribution morningReign. And yeah, its also frustrating in my case, where my intention was to have an arc of a circle that was much larger than the screen, and then to increment events on a timeline that updates every minute. In this case, the resolution of 1 degree led to huge jumps as it rounded down and then up to the nearest integer, making the UI pretty unintuitive. I imagine this is true for anyone mapping a scale to a portion of a circle's circumference that requires more than the number of degrees spanned by that portion.

 

The workaround I ended up adopting is doing some trigonometry to choose the radius of the circle such that I had a given number of degrees to work with that were onscreen; and then just updating the timeline every 15 minutes. The result actually works quite nicely; it's just not what I originally intended to do.

Best Answer
0 Votes