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

    If anything, you are making an argument for Garmin to detect that you are drawing too many white pixels and to shut your data field down, although neither of us wants to see that happen.

  • 6 months ago

    > You brought up all the white pixels as an argument, not me.

    My point was that you can't argue that pixel shifting does nothing to mitigate the 1000s of white pixels you are drawing when you should be aware that Garmin doesn't want or expect you to draw 1000s of white pixels on an AMOLED display in the first place (and in fact they would prevent you from doing so if you were developing a watchface)

  • 6 months ago

    > It's not about the white background.

    I was specifically replying to this:

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

    You brought up all the white pixels as an argument, not me.

    > This way I easily noticed it, but I would go crazy similarly if I would draw a circle and it disappears to one side.

    I never said pixel shifting is 100% desirable from the dev's or user's POV, I'm just trying to explain what you're seeing in your bug report.

  • 6 months ago

    Also, we're not talking about watchfaces here, we're talking about data fields. If Garmin applies pixel shifting to watchfaces as well, that would be a separate (but similar) argument.

  • 6 months ago

    > 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)

    Yeah like I said I've seen this argument before and I can't discount it.

    But that won't change the fact that Garmin is using pixel shifting (or not).

    I think it does make sense for thin elements like data field separators.