Memory management for complex Data Fields

Hi, I have a complex data field (running web requests from BG) that is currently just on the memory limit for some of the devices (e.g. Fenix 5). It makes it very difficult for me to continue work with it since only a few more lines of code will cause it to go out of memory. My data field uses layouts and has some bitmap resources (arrow icons), hence I cannot use a simple DF.

Ideally, I'd like to replace the bitmaps with a custom font that I have created (that includes the icons I need). Also, I'd like to start using relative layouts to automatically handle font size scaling for me, based on the width and height of the data field area. Right now I need lots of logic to fit the data nicely on every device and data field layout.

However, I understand both custom fonts and layouts are memory heavy so perhaps a very wrong approach for saving memory :-) It would just make my life a lot easier and I could remove lots of logic and complexity from the code, and it would allow me to add new devices much quicker.

Moving away from layouts to dc.writes could be a way to save memory but would also make the rendering a lot more complex to code. It seems Im stuck between a rock and a hard place on this one. Therefore seeking device from you experienced Garmin app developers. What would you have done in my place? Is there anything I haven't though of?

TIA
/Fredrik

0 flocsy🤠 over 2 years ago

1. I don't use layouts

2. I optimize many many places in my code (change a little bit, and compare the code, data size, take a note and keep the version that uses less memory)

3. I also use Prettier Monkey C to optimize even more

4. I only do bugfixes to devices with 16k memory and add new features only to devices with at least 32k.

0 flowstate over 2 years ago

Fsallstrom said:
Moving away from layouts to dc.writes could be a way to save memory but would also make the rendering a lot more complex to code.

Yep, the code for calculating your own app-specific layouts dynamically can be expensive (in terms of memory for code.)

For my memory-hungry fullscreen data fields (which need to support CIQ 1 devices), I use my own custom ad hoc "layout engine" which takes a hardcoded binary layout as an input.

- The layout data is bit-packed and I try to avoid wasting as few bits as possible

- On CIQ 2+ devices, I use JSON resources to store the layouts (this allows me to provide the user with the ability to select between different layouts, and to avoid wasting memory on the code which initializes the data)

- On CIQ 1 devices (which lack JSON resources), the layout data pretty much has to be in the app code, but I wrap it in a function so at least the data doesn't consume memory while it's not being used. (e.g. While the app is not drawing the layout, it can use the extra memory to do something else.)

0 jim_m_58 over 2 years ago

As you are doing makeWebRequest calls, you may want to look at the size and complexity of the data you get If there's things you don't need maybe consider a proxy to reduce the data.

0 Fsallstrom over 2 years ago in reply to jim_m_58

Yep, I have my own web proxy in between the client and web server that filters out all unnecessary data.

0 Fsallstrom over 2 years ago in reply to flowstate

okey, that sounds a bit to advanced for my programming skills but a very interesting approach, thank you for answering.

0 Fsallstrom over 2 years ago in reply to flocsy🤠

Thanks and sorry for a noob question: what is "Prettier Monkey C"? Is it another compiler?

0 flocsy🤠 over 2 years ago in reply to Fsallstrom

forums.garmin.com/.../big-update-to-prettier-extension-monkeyc