What does this error screen mean?

Hi Brian,

Thanks for your quick reply and explanation.

Does this mean there is no way around this limitation for the Fenix3?

This is a device limitation, and there is no way to change the behavior.

What I do notice is that after I side-load the app on my Fenix, when I open the Bike app, the transition animation is very choppy (I have the data field set as Field 1). Do you have any idea what could be the cause?
I can share code if needed..

Choppy animations indicate your onUpdate function takes a long time to complete. You can use the millisecond timer from System.getTimer() to time your update function on hardware. Screen transitions run at about 10-20 frames/second, so you will want an on update < ~50-100ms to avoid choppy animations.

Choppy animations indicate your onUpdate function takes a long time to complete. You can use the millisecond timer from System.getTimer() to time your update function on hardware. Screen transitions run at about 10-20 frames/second, so you will want an on update < ~50-100ms to avoid choppy animations.

Currently, my onUpdate function checks !=null for 7 metrics by if-else statements. I guess this is what's making it slow to execute.
Is there a better way of handling this?

Thanks for your advice!

Currently, my onUpdate function checks !=null for 7 metrics by if-else statements.

I have doubts that it is the null checks that are the source of the slowdown. Yes, a null check is not free, but it *should* be extremely cheap when compared to drawing text or a bunch of lines.

I have doubts that it is the null checks that are the source of the slowdown. Yes, a null check is not free, but it *should* be extremely cheap when compared to drawing text or a bunch of lines.

I agree... It's what is being done in those 7 "if/else if" sections that's the problem, and not the condition statements themselves.

my 7 fields RunField. I did some profiling, it takes approx 70-80ms to completely render all 7 fields. Takes between 8-15ms per datafield I DC.drawText

The fluctuations between updates are quite up/Dn. I tried to see how to reduce the update time, but maybe there's no way, or I just don't know how, but things like drawing the elapsedTime, the calculation involved to
1) convert from ms to sec
2) format the secs into hh:mm or mm:ss depending upon if I've hit >60min

Takes a hit too. 6ms to just do nothing except check if it's !=null and goes to 8/9ms once session is started.

One of the biggest hit is the 10s average calculation - up to 30ms to do that. (I shudder to think if I were to implement 30s pace averaging)

As of right now, with what Brian said about screen refresh rate and optimized value of 50-100ms, I'm not seeing opportunities to reduce that.

Anyone got any comments as to how to optimise it?

How are you computing your 10s average?

For any of these you aren't already doing, I suggest:
Compute the average in the compute() function, not in onUpdate().
Use a circular buffer.
Instead of looping through your buffer each time to accumulate, keep the accumulation, subtract the element that is being removed, and add the element being inserted (this method should have a constant compute time regardless of the buffer size).

How are you computing your 10s average?

For any of these you aren't already doing, I suggest:
Compute the average in the compute() function, not in onUpdate().
Use a circular buffer.
Instead of looping through your buffer each time to accumulate, keep the accumulation, subtract the element that is being removed, and add the element being inserted (this method should have a constant compute time regardless of the buffer size).

i don't know what is a circular buffer but it's via a predefined array of 10 fields, a every 10th field, i reset the counter back to 0 and start again.
This is done within compute() via a function of sorts then called in onupdate()

Well, that sounds like a circular buffer to me. (Contrary to shifting the items down each time data is received.)

The real question is if you are adding up the values and dividing by 10 in onUpdate(). This is what I would I think could be taking some time (you said this part took nearly half of your update time). This shouldn't be done in onUpdate(), because the result only changes when new data comes in via compute(), and onUpdate() can be called rapidly during transitions.

I also suggested optimizing the accumulation (adding the 10 numbers up) by computing it continuously.

Well, that sounds like a circular buffer to me. (Contrary to shifting the items down each time data is received.)

The real question is if you are adding up the values and dividing by 10 in onUpdate(). This is what I would I think could be taking some time (you said this part took nearly half of your update time). This shouldn't be done in onUpdate(), because the result only changes when new data comes in via compute(), and onUpdate() can be called rapidly during transitions.

I also suggested optimizing the accumulation (adding the 10 numbers up) by computing it continuously.

Nope. The summation of the 10 field array is not done in onUpdate(). It's done in a function within compute()

... Pseudo code ..
Function compute(info)
At each i (up to I = 10) fill the array with a value. Once I=10, force I=0
Sum all the values in The array.
Average over 10s = sum over 10sec/10
Return value to calling function (I call this function from OnUpdate() )


Something like that.

With the circ buffer, it can be sped up once you have a total for all 10 elements. (lets say the total is 2500)

when you are going to replace, say, the 3rd element, subtract it's value from the 2500 (say 35), and add the value of the replacement (say 45). You'd have the new total (2510) without adding everything up again.

When you are building the initial 10 your total would start at 0, and as you add an element, you add it to the current total. So you never have to run down the array and add everything up. You keep a running total of what's in the array. With 10 items it might not be a big issue, but if you used 1000 samples, you'd save a boatload of processor!