Acknowledged
5 months ago

bug: fr965 (real) 1 Field layout is off-center

Somewhat similar to https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-vivoactive5-has-bad-screen-position-for-1-field-datafield-layout-in-simulator except that this happens on a real fr965 with FW 21.19 (and it doesn't happen in the sim): My full-screen data field is added to a 1 Field layout, the default setting on the device is black background, and onUpdate starts with:

dc.setColor(Graphics.COLOR_WHITE, Graphics.COLOR_WHITE);
dc.clear();

Note that I don't use clipping in my code.

I started an activity and noticed that it's slightly off-center to the left, top. Took this screenshot, note in the right and the bottom an arc is "missing":

Then a minute later, still in the same activity it changed to this (note that now the right is OK, only the bottom is missing):

flocsy🤠
  • 6 months ago

    Why does a 1 line pixel burn in more than a huge area? Even if we're talking about a watchface with black background and any numbers displayed with a relatively big font (which is 95% of the WF-es) then it makes no sense to shift it just for this purpose, as the bigger areas will still burn in (at least the "common" pixels that are lit no matter the shifts)

    Anyway official documentation would be appreciated. Including the nature of the shifts (directions, number of pixels). I'm thinking maybe I'll draw a circle with the color of the actual background in a way that visually what the user sees will be a full white circle. But for this i need to know the line width of the circle to draw. I can't guess it for all devices...

  • 6 months ago

    > Even if all of those white pixels burned in, seems like it would be less noticeable than burned-in black text

    Sorry, I just realized this doesn't make any sense since black pixels can't "burn in" on AMOLED.

    But clearly pixel shifting would make sense for the opposite scenario: white text/lines on black background.

    And again, Garmin doesn't really want you to use a sold white background for anything.

  • 6 months ago

    > There's a reason that AMOLED devices don't even allow you to select a white background for a native watchface or activity.

    Ofc I mean *Garmin* AMOLED devices

  • 6 months ago

    > as I literally drew thousands of white pixels on the whole screen that don't move for all the duration of the activity

    > Only around the texts it will have any effect, and of course in the "edges" where sometimes we see the black arc.

    This would still tend to avoid burn-in for things like text and line graphics, which I assume is the main purpose of pixel shifting.

    Even if all of those white pixels burned in, seems like it would be less noticeable than burned-in black text

    Ofc it's not recommended at all for you to draw a data field with a solid white background on an AMOLED device (pretty sure Garmin explicitly says somewhere that black backgrounds are preferred for AMOLED). There's a reason that AMOLED devices don't even allow you to select a white background for a native watchface or activity.

    So you can hardly fault Garmin for inadequately guarding against the effects of a dev doing something that they don't recommend doing.

  • 6 months ago

    Yes, the argument that pixel shifting is generally not helpful has been made before on the forums, and it's hard to disagree.

    However, that doesn't change my belief that pixel shifting is happening, since:

    - it's been reported several times for different watch models

    - the reported behaviour (e.g. separator lines moving around) matches the theorized cause (pixel shifting) perfectly

    It would be great if Garmin could confirm or deny this tho.