Graphing altitude - optimization ideas ?

How does everyone handle graphing – specifically in a DataField ? I’ve created a basic graph that scales on both X and Y axes, but I’m scratching my head about how to best optimize it. I ran into watchdog errors while trying to draw too many data points - so I limit drawing to the number of available pixels on the x-scale (for example ~380 on an Epix2) by using a scaling/factor constant based on the size of the array. But that will still leave me with a very large array of altitude values for long activities. What would be a good way of keeping the array to a manageable size ? I thought about constantly sampling the array to only keep 380 equally spaced data values, but I’m afraid the data will get diluted and the graph won’t be very representative of the altitude profile.

Also, I haven’t found a way - but is it possible to have scroll-able/swipe-able graph like the built in ones on the watch ?

0 9635560 7 months ago

Not sure if this is good or bad, but some things that have worked for me:

1. Declare fixed size array at the start, use an incrementing start index with mod (eg: i % length stays within 0 to length for array access) so can simply write new value in correct position and have up to length-1 previous values without recreating or manipulating arrays

2. Can use BufferedBitmap to incrementally draw as drawing BB to screen is much quicker than redrawing graph

3. Rework calcs so you can update by applying newest value and removing single expired value - much quicker than iterating entire array

ps: Also, constrain graph to last n seconds of activity!

0 flowstate 7 months ago

DirtJezus said:
I thought about constantly sampling the array to only keep 380 equally spaced data values, but I’m afraid the data will get diluted and the graph won’t be very representative of the altitude profile.

Maybe, but not to state the obvious: youl'll never be able to display more data points than pixels, so you need *some* way of reducing the data, whether it's the actual data you store, or the data that you display. (Ofc it becomes more complicated if you give the user a way to pan the graph.)

If you want to reduce/sample the data you store, you could always try to store 3 values per pixel / time period: min value, max value and average. Or maybe even the average could be enough.

As a matter of fact, I think this is why ppl often complain that the all-day HR graph doesn't reflect their max HR during an activity -- bc that graph isn't storing / displaying *all* the values, just a representative sample.

DirtJezus said:
Also, I haven’t found a way - but is it possible to have scroll-able/swipe-able graph like the built in ones on the watch ?

For the longest time, data fields on Garmin watches could not accept any input at all. More recently, current watches (like FR955 and FR965) seem to support onTap() now. (Edge devices have supported onTap for the longest time -- I think every CIQ-capable Edge device with a touchscreen supports onTap() in data fields).

You still can't accept swipes, but you could have little arrows in your data field that the user can tap to pan the graph.

Ofc you have to account for the fact that many users will have the touchscreen disabled, especially on 5-button watches where 99% of the functionality is available via buttons. (On 5-button watches, the touchscreen is disabled for activities by default afaik)

So touch should really only be used for "bonus" functionality imo.