Acknowledged
2 days ago
CIQQA-3506

[BUG] Watchface onPartialUpdate() reports GraphicsTime = 1,700,000 - with no screen updates!

With no screen writes, and 3x reads of properties defined as settings; on-device and in-simulator the VM reports :

onPowerBudgetExceeded() gets triggered on all Devices and in-simulator (so at least it is consistent :) )

As these Settings Properties are stored in-memory it is unlikely Properties.getValue() can take 1,700,000uSec (1.7 seconds).
Even if that were possible, it should be reflected in Execution Time -- not Graphics Time.

Link to the Watchface working source code demonstrating this bug: https://github.com/blueacorn/Infocal/tree/2025.8.20 [note issue is fixed in mainline - reproducible on tag 2025.8.20]

Notes:

1. Properties are all defined in <setting propertyKey="@Properties...  , Settings are stored in-memory at runtime, so getValue() should not cost 1,700,000 uSecs.
2. If Properties.getValue() cannot be called in partial updates, at least make it a compiler warning,
3. The side-effect on Graphics Time is very misleading - at least move the time cost to Execution Time -- not Graphics Time.

For context, the original root-cause discussion thread: https://forums.garmin.com/developer/connect-iq/f/discussion/420832/watchface-onpartialupdate-powerbudgetexceeded---with-no-screen-updates/

J__J
Parents
  • 2 days ago

    1. As explained in the linked thread, even though properties/settings may be in memory at runtime, this is *probably* just to support the old, deprecated AppBase.getProperty/setProperty functions, which reads and writes from memory (storage [*] is only read/written at application startup/termination). I think the newer API - Application.Properties - always reads and writes to storage regardless. This is probably to avoid issues like losing changes to properties if the app crashes.

    Sorry, it's my fault that I brought up "application settings" being in the memory viewer and added to the confusion. Kind of a red herring.

    [*] I just mean non-volatile storage as opposed to RAM, not the literal Storage class

    2. This is a good idea

    3. Agreed

Comment
  • 2 days ago

    1. As explained in the linked thread, even though properties/settings may be in memory at runtime, this is *probably* just to support the old, deprecated AppBase.getProperty/setProperty functions, which reads and writes from memory (storage [*] is only read/written at application startup/termination). I think the newer API - Application.Properties - always reads and writes to storage regardless. This is probably to avoid issues like losing changes to properties if the app crashes.

    Sorry, it's my fault that I brought up "application settings" being in the memory viewer and added to the confusion. Kind of a red herring.

    [*] I just mean non-volatile storage as opposed to RAM, not the literal Storage class

    2. This is a good idea

    3. Agreed

Children
No Data