SDK 8: Disable radial/angled text drawing if a product does not have a GPU

My educated guess is that drawing radial or angled text indeed requires a GPU, which is why drawRadialText is unavailable for CIQ 4+ devices which lack a GPU, such as Vivoactive 5. (This is reflected in both *.api.debug.xml in the device library installed by the sdk manager, and in the api documentation)

I did verify that Graphics.Dc has :drawRadialText and Graphics.Dc has :drawAngledText are false for a simulated vivoactive5 and true for a simulated fr165, whether or not --disable-api-has-check-removal is set as a compiler option (meaning it's false at both compile-time and run-time, in the simulator). I tried this on both 7.4.3 and 8.0.0-beta, with the same results.

This suggests to me that as far as API has checks go, radial text and angled text are indeed only available to devices with a GPU.

As for this exact bullet point:

"Disable radial/angled text drawing if a product does not have a GPU."

I'm not sure why this change would be necessary at all, since drawRadialText is already gated at the product level (it's apparently restricted to devices which have a GPU). But it stands to reason that there must have been *some* loophole which allowed the dev to attempt to draw radial text on a newer device which doesn't have a GPU (such as vivoactive5), and I assume that the attempt would simply fail (or crash).

I assume that the change was made to avoid the hypothetical scenario outlined above.

flocsy🤠 said:

If I understand correctly what this means then someone who 2 days ago could release their app and it uses angled or radial texts, now won't be able to compile (in the good scenario), and in worst case the app already released will stop working or will crash once the users upgrade to the latest firmware.

To address this precise concern:

- I don't see how any dev could've successfully used drawRadialText and drawAngledText on a newer device which lacks a gpu (such as vivoactive5), since those functions do not exist on those devices (or at least, vivoactive5)

- Then again, there must have been *some* way to attempt to draw radial text or angled text on such a device, otherwise the change described in the bullet point would be unnecessary

As a sanity check, I looked at an old backup of my devices folder from April 2024 -- back then (same as now), vivoactive5 did not have drawRadialText or drawAngledText in vivoactive5.api.debug.xml, meaning the device file did not change in that respect either.

Anyway, maybe someone from the CIQ team will chime in here.

My impression is that a "has" for drawAngledText or drawRadialText will now be false on devices that don't support getVectorFont (which already works with "has".

You already can't use drawAngledText or drawRadialText with a standard font, and this may be a way to detect something like that sooner.

Looking at the local API docs for 7.4.3 and 8.0.0-beta, it seems that the opposite has happened.

- In 7.4.3, the lists of supported devices for getVectorFont, drawAngledText and drawRadialText are identical

[1/4]

- In 8.0.0-beta, drawAngledText and drawRadialText gained a few extra supported devices [according to the api doc], which were added to the bottom of the list [instead of being added in sorted order]:

• D2 Air X10
• Venu® 2 Plus
• Venu® 2
• Venu® 2S

These 4 devices have "enhancedGraphicSupport": true in compiler.json, which is said to indicate the presence of a GPU.

[2/4]

[3/4]

I also seem to recall there have been questions in the past about why certain devices with "enhancedGraphicSupport": true do not support all of the seemingly "gpu-related" functions. Perhaps this is one example of where this type of deficiency has been addressed?

However, the corresponding *.api.debug.xml files for those 4 devices still don't contain drawRadialText or drawAngledText (unlike the other devices which are supposed to support those functions)

And it's not clear why the change would be tied to an SDK version (8.0.0-beta) and not a device update [which is not versioned.]

I only have more questions now :/.

[4/4]

And this should be "normal" because all devices used the same SoC since Venu 2 released in 2021.

MRT595SFFOC

"this processor has a GPU. It’s for 2D vector graphics and can run at 200 MHz speed. Garmin Venu and Epix has AMOLED screens with higher resolution displays with support for much more colours."

http://www.f-blog.info/garmin-fenix-7x-solar-teardown-non-destructive/

---

According to some tests, FR945LTE should ne concerned too, but API Level or Garmin "flag" could explain the exclusion ?

So maybe this item in the bug fixes section of the changeling just meant to say they fixed the documentation, just got out in this confusing wording?

Except the doc no longer matches the device config, so does the config for those four devices have to change too? That’s why I have even more questions now. I guess rather than looking at the *.api.debug.xml files, I could try the actual has checks when I have a chance. But I would assume that the debug info for symbols should match the behavior of the has checks, in general.  

socorsu said:

According to some tests, FR945LTE should ne concerned too, but API Level or Garmin "flag" could explain the exclusion ?

As discussed previously, 945LTE shipped with CIQ 3 (for whatever reason), only CIQ 4+ supports GPU related features, and Garmin decided that no device with CIQ 3 would ever get CIQ 4 (at the time it was speculated that this is bc CIQ 4 requires a GPU, which only calls into question the decision to make 945LTE a CIQ 3 device). 

Could be that Garmin wanted to give people a reason to get 955 (ie CIQ 4, but since when did Garmin use CIQ as a marketing carrot), or maybe 945LTE started development too early for CIQ 4. (Then again Venu 2, which has CIQ 4, was released first — could still be that 945LTE dev was started first, and it took longer to finish, perhaps due to long LTE certification times, which have been cited as reasons that firmware wasn’t updated as fast as ppl would like.)

I do know that 945LTE makes use of translucency on the map page, so it seems that at least some native code might make use of the GPU after all. I would also guess that the GPU might also facilitate fast smooth scrolling which tracks your finger (which is seen on all modern touchscreen Garmin watches). In contrast, Garmin’s really old touchscreen FR630 would only scroll one page at a time, making for a terrible touch UX.