Acknowledged
CIQQA-3254

vivoactive 6 - screen becomes cropped

Hello Garmin-Team,

a user of a vivoactive 6 reported, that a watchface is beeing cropped on the right side and bottom:

With SDK 8.1.1 there's no problem.
That behavior is not reported or known by any other watch types.
I have 2 real devices for testing: fenix 7X sapphire and Venu 3 (see photos).

dc.setClip ist NOT used anywhere in the code.
I've got no idea, where that should come from.
Could there be a bug in the firmware or in the ConnectIQ SDK-data?

Greetings, Ronny

1076493
  • in reply to 1076493

    I'm not sure if there's a clipping at 430, but if there is then there might be a reason for it, i.e hardware constraints. So maybe it's not just changing that number to an arbitrary, bigger number. And even if they could do that, why would they do it according to your arbitrary number 560? Other devs will ask for 640 or 800. Maybe you should try to change your code to draw to a smaller area 

  • Hallo   and Garmin team,

    after more than one year, I think I've found the reason for that behavior.
    For drawing the watchface I use an offscreen buffer bitmap, because I use fonts, that are not scaleable. To stay safe for future watches I've chosen an offscreen buffer size of 560x560 pixels with appropriate scaled fonts. I've chosen that large size, to have enough pixel for future watches (as we can see - regarding to the new fenix 9 Pro - that's a good idea). The large offscreen buffer is after completion resized with an affine transformation to the display size. That works fine in the simulator of SDK with ALL watch types and obviously on nearly most of the real watches. Only the vivoactive 6 does not work that way.
    Error tracing for vivoactive 6:
    The screensize of that model is 390x390 pixels --> the cropping (see picture linkclipping at vivoactive 6) is at x=300 and y=300
    That means: (300 / 390) * 560 = 430 --> obviously the content of an offscreen buffer bitmap could not be larger that 430px by 430px, if it should be displayed completely. 
    So finally: an offscreen buffer bitmap is allowed to have any size, but theres an internal firmware-clipping at x and y = 430.
    If that clipping really exists it could be fine, but then the simulator of the SDK should do it the same way.
    Could your please evaluate that behaviour with that assumption and maybe delete that clipping at real devices?

  • OK, well, I just saw the image in the email now. For some reason I don't see it here in the desktop Chrome... So no, I guess it's not the pixel shifting. That would only shift it by a few pixels.

  • It's probably the pixel shifting of AMOLED displays. It's annoying. You can also see it in the simulator sometimes ( maybe it could be added to the simulator somehow in a way that developers would be able to trigger the shift to be able to see how their screen will look in all shift directions?)