Acknowledged

Bug: Boundary on Epix2 fields is off

In addition to this graphics defect: https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-graphics-text-on-epix2-difference-in-real-life-vs-simulator

it also seem field boundaries are sometimes wrong or off ... I'll add a picture with a clear example of this. I fill the field with a color - which show the problem in the the center divider line is not in center. Plese fix these problems with Epix2 !! 

Parents
  • Thanks!

    Not sure still what to learn from these?

    TL;DR I found that in the first 2 screenshots:

    - the red fields are 1 pixel too tall (compared to the device reference)

    - the horizontal and vertical dividing lines are actually moving around (probably to prevent AMOLED burn-in). This explains why the lines either overlap the fields or are too far away from them

    --

    The screenshots are pixel-perfect representations of what's being drawn to the device screen (notice each one is exactly 416 x 416). We can open them in an image editor and determine exactly where everything is being drawn, and compare that to what Garmin says it should be in the device reference.

    So we could see whether it's actually the data field boundaries that are off, or whether the dividing lines are being drawn in the wrong place, or both.

    It's just additional information / evidence to support the bug report.

    e.g. the first screenshot you posted is field 3 of a 6 fields layout. The docs say that field 3's coordinates should be x/left = 209 and y/top = 105. Looking in image editor, the actual coordinates seem to be (209, 104). The docs also say that the width of the field should be 207 and the height should be 102. The image editor says (207, 103). So we've already identified a couple of discrepancy (or one discrepancy, depending on how you look at it).

    Taking a look at the 2nd screenshot - Field 4 of a 6 fields layout:

    - Docs: (x, y) = (0, 209). (width, height)  = 207, 102)

    - Screenshot: (x, y) = (0, 208). (width, height) = (207, 103)

    So both field 3 and field 4 are 1 pixel taller than the documentation specifies.

    It's also interesting to note that the center lines are actually 2 pixels thick, so in all cases, we should expect the fields to touch, but not overlap, the adjacent lines.

    One really strange thing I see in the screenshots is that the center lines aren't in the same position from screenshot to screenshot, even for the same layout.

    In the first screenshot, the lower vertical line is at (207, 222) but in the second screenshot, it's at (210, 227)

    The horizontal dividing line moves similarly.

    So actually, placement/size of the data fields aside, I'm starting to think this isn't a bug (the part about the dividing lines moving around, at least). Epix Gen 2 is an AMOLED device, so I'm guessing the dividing lines are moving around on purpose, to prevent burn-in.

    Whether the fields themselves are also moving around is a different question. If they were, I might:

    - still expect the width and height to be correct (but the height is wrong for at least two of them.)

    - expect to be able to observe this with multiple screenshots of the same field

    - expect them to move in the same way as the boundary lines

    I'm gonna guess the fields themselves aren't moving, or at least they're not moving in sync with the dividing lines.

Comment
  • Thanks!

    Not sure still what to learn from these?

    TL;DR I found that in the first 2 screenshots:

    - the red fields are 1 pixel too tall (compared to the device reference)

    - the horizontal and vertical dividing lines are actually moving around (probably to prevent AMOLED burn-in). This explains why the lines either overlap the fields or are too far away from them

    --

    The screenshots are pixel-perfect representations of what's being drawn to the device screen (notice each one is exactly 416 x 416). We can open them in an image editor and determine exactly where everything is being drawn, and compare that to what Garmin says it should be in the device reference.

    So we could see whether it's actually the data field boundaries that are off, or whether the dividing lines are being drawn in the wrong place, or both.

    It's just additional information / evidence to support the bug report.

    e.g. the first screenshot you posted is field 3 of a 6 fields layout. The docs say that field 3's coordinates should be x/left = 209 and y/top = 105. Looking in image editor, the actual coordinates seem to be (209, 104). The docs also say that the width of the field should be 207 and the height should be 102. The image editor says (207, 103). So we've already identified a couple of discrepancy (or one discrepancy, depending on how you look at it).

    Taking a look at the 2nd screenshot - Field 4 of a 6 fields layout:

    - Docs: (x, y) = (0, 209). (width, height)  = 207, 102)

    - Screenshot: (x, y) = (0, 208). (width, height) = (207, 103)

    So both field 3 and field 4 are 1 pixel taller than the documentation specifies.

    It's also interesting to note that the center lines are actually 2 pixels thick, so in all cases, we should expect the fields to touch, but not overlap, the adjacent lines.

    One really strange thing I see in the screenshots is that the center lines aren't in the same position from screenshot to screenshot, even for the same layout.

    In the first screenshot, the lower vertical line is at (207, 222) but in the second screenshot, it's at (210, 227)

    The horizontal dividing line moves similarly.

    So actually, placement/size of the data fields aside, I'm starting to think this isn't a bug (the part about the dividing lines moving around, at least). Epix Gen 2 is an AMOLED device, so I'm guessing the dividing lines are moving around on purpose, to prevent burn-in.

    Whether the fields themselves are also moving around is a different question. If they were, I might:

    - still expect the width and height to be correct (but the height is wrong for at least two of them.)

    - expect to be able to observe this with multiple screenshots of the same field

    - expect them to move in the same way as the boundary lines

    I'm gonna guess the fields themselves aren't moving, or at least they're not moving in sync with the dividing lines.

Children
No Data