Syntax of Graphics.fillPolygon.

I'm trying to understand the syntax of Graphics.fillPolygon.
As the attached screenshot shows, when I submit an array
[[4, 75], [4, 83], [8, 79]] I actually get a polygon filling the following points
[[4, 76], [4, 82], [7, 79]]

For future graphics work, I wonder what algorithm the SDK is using?

PUFFOLINO over 7 years ago

Have you ever checked the drawLine or drawRectangle results? I have observed some one pixel shifts in some situations, so I usually define constants now to be able to do fine tuning when necessary. On the other hand, constants seems to expand the resulting prg file, but that's another story...

Alan.raceQs over 7 years ago

Have you ever checked the drawLine or drawRectangle results?

Thanks for your suggestions for further study, which might shed some light on the issue, but it seems crazy that we developers have to invest time and effort in reverse engineering an SDK class to deduce its specification that the authors have overlooked include in the documentation.

all we have is

pts (Toybox::Lang::Array) — Array of coordinates with a 64 point limit

with no explanation of how it deals with the pts.
Does it matter if the array is ordered clockwise or anti-clockwise?
Are the points inclusive or exclusive?

C'mon Garmin....

Former Member over 7 years ago

There are a lot of issues with the details of the graphics APIs, and unfortunately I can't offer much beyond an apology in the short term. Long term, we plan to spend time giving the graphics module the attention it needs. If you see any more discrepancies like this one, please continue to report them. I am filing tickets to address these types of errors. Any drawing accuracy issues should be high on our priority list when this work gets rolling.

Alan.raceQs over 7 years ago

Please don't "fix" the graphics API

Just because it doesn't work like I expect doesn't make it a discrepancy.

The problem is that my expectations don't match the design of the API but we don't know how it was designed to work. I'm sure the developers tested it thoroughly and were satisfied it worked to their spec.

It will be a nightmare if, this late in the day, you "fix" the API- as our code, which now works, will fail with the fix.

Far better to leave the API as it is, and to publish the spec against which the API was developed.

Former Member over 7 years ago

It will be a nightmare if, this late in the day, you "fix" the API- as our code, which now works, will fail with the fix.

I am well aware of this issue. It affects the native interfaces on the device just as much as Connect IQ. We will be attempting to add corrected APIs without eliminating the broken ones wherever possible.

Far better to leave the API as it is, and to publish the spec against which the API was developed.

The API is far to busted to do nothing. There is no real spec to publish. The APIs internally indicate the same thing they do externally and simply do not behave as they should in several places. How can I publish a specification for fillPolygon() that says it draws a shape 1 pixel smaller than all the points you specified? Computationally, how do you account for this type of error? You can't determine if you should add one to a point, or subtract one without re-implementing an algorithm used to draw the shape.

Coleman.Apps over 7 years ago

I did some digging on this one. It spent some time being investigated at a lower level and now has made it back to us (very recently). There are some API level changes that would have to be made that would break everything that is currently using the fillPolygon() call. This leaves us in a bit of tight spot as far as any changes that we can realistically make on this one right now.

Thanks,
-Coleman