Why do custom watch faces ALL cause serious lag on button presses

Don’t know the answer but it’s very frustrating!

Ask the question of the developers of the relevant watch face.

Given that it happens with every single watchface regardless of developer, I’d say it’s not their issue specific. 

I guess the Enduro has the same hardware as the newer Fenix 7 and Epix 2, and Garmin tried to do as much power saving on the Enduro via software as possible. As a consequence, it probably takes forever for some tasks to wake up, and they only get a small amount of processing power assigned. Internal watchfaces are probably less of a battery hog and therefore are internally not treated the same way.

No. The Enduro is definitely not the same as the fenix 7 series. It’s a derivative of the fenix 6X Solar. Same GPS chip but something to make it more fuel efficient. Maybe a different ARM processor or maybe just downclocking a bit for incremental gains. The 7X series has generational improvements in performance and power efficiency that suggest a process node shrink at the heart of it. 

I think it has to do with the overhead of ejecting the MonkeyC VM used by ConnectIQ from memory. The native watch faces seem to be fully compiled and linked into the OS while custom faces are running in a virtual machine which is why they consume more resources. 

brian.reiter said:

No. The Enduro is definitely not the same as the fenix 7 series. It’s a derivative of the fenix 6X Solar. Same GPS chip but something to make it more fuel efficient. Maybe a different ARM processor or maybe just downclocking a bit for incremental gains. The 7X series has generational improvements in performance and power efficiency that suggest a process node shrink at the heart of it. 

What I meant was that the Enduro probably uses the same new ARM CPU chip as the F7 and E2, which has smaller nm-stepping, but the old GPS chip like the F6. I remember reading Garmin telling DCR that the Enduro was 'a totally different platform', or something like that.

brian.reiter said:

I think it has to do with the overhead of ejecting the MonkeyC VM used by ConnectIQ from memory. The native watch faces seem to be fully compiled and linked into the OS while custom faces are running in a virtual machine which is why they consume more resources. 

ok but, it seems to not be the case with other watches (i had the instinct 2 and this issue doesn't exist), so why this watch and not the other one.

it could be interesting to have the answer of a garmin staff, to not have to make uncertain assumptions

Have you contacted the developer of the watch face(s) in question? Perhaps they're not programming efficiently?