Working around the lack of an XTINY font on the Fenix 5

I just posted this image in another thread showing the difference in the font sizes between the Fenix 3 and the Fenix 5.



And it got me wondering if anyone else is experiencing some challenges porting apps to the Fenix 5 with the loss of a truly extra tiny font? I know that there's nothing to be done really other than use a custom font as a workaround but I'm curious if anyone else relies on the extra tiny font to display "nice to have" info but without sacrificing too much screen real estate.

I'm guessing the authors of some of the popular and complex watch faces, like ActiFace and GearMin, will be challenged to port their watch face over the Fenix 5 series while at the same time keeping the look the same. Even keeping it close to the same might be a challenge given the dramatic difference in size between XTINY on the two devices.

Cheers,
Douglas
  • Thanks for the thorough explanation guys; I understand all that. What I mean was I don't understand why arrays (single or multidimensional) would be implemented the way that they have been. Yes, it's certainly a solution (albeit a memory hogging solution) but is it because we are running on a hardware device or is it simply a design/implementation choice?

    I also understand it from a reference count perspective, but again, there is no need to maintain a reference count for the contents of an array when you implement arrays as a contiguous block of memory. In any case, maybe I'm just over-thinking it. And of course, if Garmin increased the available memory even a little bit this wouldn't even be an issue.

    Cheers,
    Douglas
  • In effect, the 2) above is using as flat a memory space as you can with mc. One created, and based on what you store in it, it stays the same size, memory wise, and you manage it like you would if it were just a memory pointer and a chunk of space (pointer and offset). As things aren't typed in mc, you can't say you want to define an array of 100 doubles, which would reserve what's needed for that, vs an array of 100 characters, which would take much less space.

    Using the lat/lon thing, if you store them in the array as floats, the memory usage will not change as things are added, for example.
  • In effect, the 2) above is using as flat a memory space as you can with mc. One created, and based on what you store in it, it stays the same size, memory wise, and you manage it like you would if it were just a memory pointer and a chunk of space (pointer and offset). As things aren't typed in mc, you can't say you want to define an array of 100 doubles, which would reserve what's needed for that, vs an array of 100 characters, which would take much less space.

    Using the lat/lon thing, if you store them in the array as floats, the memory usage will not change as things are added, for example.


    Right. And I forgot that with dynamically typed languages we can't track the size of the individual elements, which is required since the array is not necessarily of a single type.

    Luckily you guys are around to straighten me out.

    Note to self: drink more coffee before attempting to deal with memory and compiler issues. :)

    Cheers,
    Douglas
  • It is long time and still fenix 5 has the same issue with XTINY and TINY fonts. I think it is time to solve it and have a good regular and small XTINY font as all the other devices has!! :-D I usually struggle a lot to find the correct font for the small text and it is a bit annoying adding resources for what it should be already in... :)

  • The fonts will not change after 6 years.  If they did it could break a whole bunch of existing apps

  • I know but i'm a luckly owner of a fenix 5x plus... :-D What about adding a new xtiny font with a different name? Such as XXTiny :-D

  • You can do your own custom font.  After all this time, nothing will change in the base FW and no new FONT_* will be added..

  • Yes i added custom fonts, but as i wrote before is a little bit annoying. Anyway thank you for the answer.. seeya