Acknowledged
1 month ago

Application.Storage.setValue()'s 2nd argument (value) is not typed (or documented) to take a BitmapReference, but it should be

This has led people to incorrectly believe that it's not possible in CIQ 4+ to use makeImageRequest in a background process and somehow pass the image back to the foreground process, since Storage.setValue() is the only conceivable way to do this in a CIQ 4+.

Note:

- makeImageRequest returns a BitmapReference on CIQ 4+ devices, BitmapResource on earlier devices.

- Background.exit() does not work with a BitmapReference (and you can't change the BitmapReference into a BitmapResource, in the background process.).

I would love to post the example code, but the forum is codeblocking me as per usuge. Here's a pastebin: https://pastebin.com/BEecnzCa

I will post a screenshot in the comments.

The example code works fine (the foreground process is able to call Storage.getValue() and draw the bitmap), so it's clearly only an issue with the type checker.

FlowState
  • 1 month ago

    > To circle back to this:

    Thanks for those additional clarifications. I have gradually come to the same understanding.

  • 1 month ago

    > One use case for get() would to be store returned reference in a variable (which would have the effect of locking the resource in the graphics pool for as long as the reference is alive)

    I would imagine that it would not be recommended to purposely lock a resource in the graphics pool for any longer than necessary, though. (Since all apps have to share the pool.)

  • 1 month ago

    > I had been calling Storage.getvalue() every second in my onUpdate() function, but I guess it would be better to use .get() on the returned BitmapReference to obtain the object itself, and then to use that.

    To circle back to this:

    - You shouldn't have to explicitly use get() in most cases, since Dc.drawBitmap() and drawBitmap2() accept BitmapReference as well as BitmapResource

    - One use case for get() would to be store returned reference in a variable (which would have the effect of locking the resource in the graphics pool). Another use case could be to call public functions on the BitmapResource class itself, like getWidth()..

    - If a graphics resource is not locked in the graphics pool, then the graphics pool will automatically cache, load and unload the resource from the file system as necessary

    As per the docs (https://developer.garmin.com/connect-iq/core-topics/graphics/#graphicspool):

    "All the drawing primitives that accept resource objects also accept references so your app should not have to be reworked to take advantage of the new system."

    Consider the following code:

    resource1 = WatchUi.loadResource(...); // assume resource1 is a member variable
    resource2 = Storage.loadResource(...);  // assume resource2 is a member variable

    On both older devices [without a graphics pool] and newer devices [with a graphics pool], I think the best strategy is:

    - keep both resource1 and resource2 "alive" in your app for as long as you need them [i.e. do not set either variable to null]. The exception here, as noted before, is if your app uses a large number of resources, different sets of resources for different state, and the states don't change too often. In this case, you may wish to load the different sets of resources on demand, especially if your app needs to support old devices without a graphics pool

    - pass resource1 and resource2 directly to the various graphics functions, like Dc.drawBitmap() [bitmap resource] or Dc.drawText() [font resource].

    In other words, for the most part, your code really shouldn't have to know whether it is dealing with a BitmapReference or a Bitmap Resource.

  • 1 month ago

    > look at how slowly map tiles are rendered

    I mean when you pan (for example)

  • 1 month ago

    > Plus even an old slow spinning HDD would be so much faster than Garmin's slow flash.

    That's what I'm guessing anyway. I'm sure that a modern SSD (or even older SSD) would be much faster than Garmin's flash.

    If you have a map-enabled Garmin, look at how slowly map tiles are rendered. My understanding is that part of the slowness is due to slow flash (combined with low amounts of RAM).