Acknowledged
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/

Parents
  • > Properties.setValue() does update the in-memory copy.

    That's good to know, thanks!

    I stand by my guess that the in-memory copy is probably just there for the old API.

    Although it is somewhat ironic that the new API is obligated to update the in-memory copy on setValue, but also (apparently) obligated *not* to read from the in-memory copy on getValue. I totally get it though - Garmin has wanted to remove the old API for years, and the only reason they haven't done is because devs won't stop using it.

Comment
  • > Properties.setValue() does update the in-memory copy.

    That's good to know, thanks!

    I stand by my guess that the in-memory copy is probably just there for the old API.

    Although it is somewhat ironic that the new API is obligated to update the in-memory copy on setValue, but also (apparently) obligated *not* to read from the in-memory copy on getValue. I totally get it though - Garmin has wanted to remove the old API for years, and the only reason they haven't done is because devs won't stop using it.

Children
No Data