• Replies 9 replies
  • Subscribers 18 subscribers
  • Views 742 views
  • Users 0 members are here
Options
Related

Always On Display - Implementations (Jumping vs Static)

Michael
6 months ago

How do you decide which AOD implementation you use?

There has been following requirements in the past that did change over time:

  • switch pixels and don't use the same ones consecutively
  • don't use more than 10% of the pixels
  • don't use more than 10% luminance

Based on that, how do you know which type of AOD you need to implement for each watchface?

I'm unsure what I can derive from the CIQ Version and what from the watchface model...

  • 6 months ago

    So this is just my educated guess, but I would say:

    - CIQ 3: "OG Venu rules" (whatever they are)

    - CIQ 4: 10% pixels max

    - CIQ >= 5 (System 7): 10% luminance max

    I don't develop AMOLED watchfaces, so take all of this with a grain of salt...

    Sources:

    As per the compiler.json files in the SDK's Devices folder:

    - The original Venu is stuck on CIQ 3

    - All other AMOLED devices are on CIQ 4/5

    [https://developer.garmin.com/connect-iq/user-experience-guidelines/watch-faces/]

    [https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/welcome-to-system-7]

    Always on Always

    The original Venu was the first Connect IQ device with an AMOLED screen and introduced the heuristics to avoid screen burn-in. Newer devices allow watch faces to keep the screen on in “Always On” mode if the screen is using less than 10% of the display pixels.

    With API level 5.0.0, we are updating the heuristic from one based on pixels to one based on luminance. Now the screen will stay on if the display is using less than 10% of the total luminance. This allows you to use more pixels.

  • 6 months ago in reply to FlowState

    thank you very much, that helps.

    If I remember correctly, there is no way to check the CIQ version dynamically (like :has), is there?

  • 6 months ago in reply to Michael

    Use System.getDeviceSettings() and inspect monkeyVersion in the returned DeviceSettings object.

    Michael said:
    dynamically (like :has)

    Note that recently, the compiler has been improved so that has checks can be done at compile time (which means they may be optimized away so they don't execute at run time.) This is nice for optimization, but it also means that has checks may not work as intended if a device gains a new feature after a given version of your app was compiled and released to the store. IOW, you may want a has feature check to work without recompilation, when a device gets that feature, but this new optimization prevents that from happening.

    If you want to prevent has checks from being optimized away, add  --disable-api-has-check-removal to the compiler command line.

  • 6 months ago in reply to FlowState

    thank you very much. I was aware of the new :has optimization anyways already. In my case I prefer the optimization.

  • 6 months ago in reply to Michael
    Michael said:
    I was aware of the new :has optimization anyways already. In my case I prefer the optimization.

    Cool. Just wanted to make it clear that has is no longer as dynamic as it used to be.

  • 6 months ago in reply to FlowState

    There is a compiler flag if you want to do "has" the way it's been done in the past

    -disable-api-has-check-removal

  • 6 months ago in reply to jim_m_58
    jim_m_58 said:

    There is a compiler flag if you want to do "has" the way it's been done in the past

    -disable-api-has-check-removal

    FlowState said:
    If you want to prevent has checks from being optimized away, add  --disable-api-has-check-removal to the compiler command line.
  • 5 months ago

    Does anyone of you know if burn ins can theoretically happen on a watch that allows static AOD displays? Does garmin guarantee that (or at least take the responsibility for it)?

    I ask because I wonder if I should show a static AOD with 10% pixels/luminance if possible or if I should allow the user to decide if he really wants to use a static AOD instead of the "jumping" one that I use currently.

  • 5 months ago in reply to Michael

    Idk what Garmin guarantees, but I do know that on AMOLED devices, Garmin utilizes pixel shifting on native activities. (Devs noticed that the data field separator lines move around periodically.)

    Not to be super cynical, but if you give the user a choice, they will just blame you if they pick the “wrong” choice and happen to experience burn in.