2-3 second delay in switching away from a watchface

What FW do you have on the Intinct2?  Just checked again on an I2 with my own watch faces and glances seen from up/down, and things change in less than 1 second. - pretty much as soon as I release the button.

How much are you doing when the WF starts?  At that time you could be seeing a bunch of onUpdate calls and if you are doing a bunch of stuff there it could slow things down. Same if you do a bunch when exiting (especially if you are saving stuff to Storage, for example as Storage access can be slow.)  

The processor on the I2 may also be slower...

Maybe try the simple watch face generated with the template (Monkey C: New Project) and see if you have the delay there too..

This is a known issues that has been for years. 
if you have a CIQ watchface that has a lot on the screen it has a couple of seconds delay. Until the paint is done. I have not figured how to stop it unless you do little stuff in onUpdate. Even if you try to optimize and precalculate values in onUpdate and have many datafields and filled up watchface, this will happen. The native ones will not suffer from this, it has been addressed, but I guess it will not change.

Newer Epix2 works pretty well when pressing up and down, but activating the flashlight has a significant delay, I don’t know what happens. Even Epix2 Pro has like 2-3 sec delay before the light comes on.

This was a bigger issue back in the days of many slower devices.  What I've done, is when an app starts, the app knows that and can track how many times onUpdate is called.  So the first onUpdate, I'd only calculate/show some of the data, and do the rest in the next call or two to onUpdate (a second or so later).  The result was the user would see something happening right away so there wasn't such a visible lag - something showed (while not complete) right away.

They can't put a faster CPU in current devices...

Guys, you have a nice discussion about how to optimize the start of a WF, but the question is about the "stop"...

Exactly so.  59 out of 60 times, users are not pressing a button exactly when an onUpdate() is running so how can the length of onUpdate() be the cause?  I am not saving anything or doing anything in onStop(). 

I don't have an Instinct 2 to try things out myself.   

Like I said, I've also seen an issue like this the first time onUpdate is called with some apps, and I split things up between the first 2/3 times it's called when the app starts so the lag isn't so visible.

None of my watch faces have this issue and I have an I2 in my hand.

What "issue" they don't have? The "start up" issue that only you are talking about, or the "stop" issue when you see the WF and you press up or down?

trudelta said:

59 out of 60 times, users are not pressing a button exactly when an onUpdate() is running so how can the length of onUpdate() be the cause?

I could be wrong, but I think the implication with the onUpdate() discussion is that when a user presses a button, they are usually looking at their watch, and in order to look at their watch, they probably turned their wrist, which activates high power mode where onUpdate() is called once per second for several seconds (on both AMOLED and MIP.) So in this case, the chance that onUpdate() is running when the user presses the button is much higher than 1/60.

Have you tried doing the same test with the watch in low power mode? e.g. Take your watch off, set it down on a table, wait for it to go into low power mode, and press the UP or DOWN button. If you see the same problem, then obviously it's not an issue with onUpdate() (although it could be a problem with onPartialUpdate(), if your watchface implements it.)

The start up.  My watch faces start on the I2 without any delay.  And there is no delay moving back and forth to the glances or activities.