watch face start lag

Former Member
Former Member
Hello, everyone,
I'd like rise question related to watch face performance.

I decided to start new thread, although I already asked if there are some kind of optimization guidelines before, but I consider that question closed due to advices provided and the observed over the course of the year fact, that data field lags are almost always related to FIT file write operations, since they occur regularly during activity recording (at least on my already obsolete ForeRunner230 comparing it with current generation Garmin devices) and are noticeable even using completely native data screen setups.

My current question is related to watch face start lag. Problem is that any ConnectIQ watch face built with the latest SDK's be it downloaded from Garmin market or built by me for my specific device (FR230), takes at least two seconds so start. This gives me very annoying and noticeable lag when scrolling through even native widgets let alone IQ widgets, that write properties thus providing additional lag. It's not experience breaking, but is unexplainable at the very least.

I do not compare this performance with native watch face, which starts instantly, but with my own watch face, which was last updated at 2016.09.23, meaning SDK 2.1.3 was used, and, almost surely, I compiled using option "Build for device with SDK version 1.2.x", which was the default setting and was there for that SDK version. This watchface loads bitmap font containing full screen (215x180) "face frame" and 4 more 27x27 sized symbols to display different states, in addition to this during any onUpdate it draws from 3 to 6 diffently colored arcs 15 pixels thick with half screen radius and several more drawText statements. So, you can see, that this one is not of the "lightest" ones, which may just draw time using native fonts. This watch face starts almost instantly, having not more than 500ms lag.

Problem is that I'm unable to reproduce this performance any more using available SDK's (i tried every SDK versions from 1.1.4 to 2.2.1 with different "Build for device" options). Starting with the watch face generated by ConnectIQ plugin by default I get from 1.5 to 3 sec start lag, while my watch face mentioned above (and I'm already afraid to update it to presumably loose such performance after rebuild) continues to provide outstanding performance.

I tried to compare manifest options (e.g. removed minSDKVersion tag, changed 'xmlns:iq="www.garmin.com/.../connectiq"' version from 3 to 1), build options, removing additional code, removing layouts, adding timestamps to log at different execution phases (with an exception of overall degraded performance due to write operations, this gave me milliseconds difference with overal value from application onStart to the end of onUpdate being less than a second) but even the simplest watch face, which just clears screen, reads clock time and draws current hour in the center of the screen takes about 2 seconds to start when either scrolling from widgets or exiting back from system or app menus. Standard Analog sample and default watch face generated by Eclipse plugins are good examples of this behavior. Thus I consider that this lag is the time required by ConnectIQ platform to initialize and start watch face. But then it's not clear why even larger by size (prg file if 24kb) application with rather "heavy" drawArc statements even able to redraw in scrolling animation meaning at least 3 times per second?

Therefore I wanted to ask if there are additional things I didn't try, considering there is an IQ watch face built by me during late September, which works differently on my specific watch.
Please, If anyone can share the knowledge or provide additional tips on how to research this situation, do not pass this thread, any help is welcome.
  • On a 230 (6.30 FW), I don't see what you see with my watchfaces. Screen switching is the same if I go to or from a native widget (or CIQ widget), to or from the activity list, etc. (less than 1 second - the watchface shows right when I take my finger off the button). (mine are likely all built with the 2.1.4 SDK or later)

    The 230 is slower than watches like the 735, as the 735 has a faster processor. (see the Tree Benchmark)

    Is your watchface in the app store? If so, I could try it. If not, maybe post your code?

    What FW is on your 230?
  • Former Member
    Former Member over 8 years ago
    Thank you for your reply, Jim.
    If you have time, please check this on your FR230 and share the results:
      here my rather heavy calculation wise watchface, which works "nice" by my standards, also, there's a development build () which I use personally, nothing changed vs market version, but maybe development one will behave differently somehow,

      below is the default watchface generated by IQ plugin, which gives me from 2 to 3 seconds lag when built for FR230 with Connect IQ SDK 2.1.5 set as current in my Eclipse for target SDK 1.3.x (the only one available for this IQ SDK version):


    WFPerfTestApp.mc
    using Toybox.Application as App;

    class WFPerfTestApp extends App.AppBase {

    function initialize() {
    AppBase.initialize();
    }

    // onStart() is called on application start up
    function onStart(state) {
    }

    // onStop() is called when your application is exiting
    function onStop(state) {
    }

    // Return the initial view of your application here
    function getInitialView() {
    return [ new WFPerfTestView() ];
    }

    }


    WFPerfTestView,mc
    using Toybox.WatchUi as Ui;
    using Toybox.Graphics as Gfx;
    using Toybox.System as Sys;
    using Toybox.Lang as Lang;

    class WFPerfTestView extends Ui.WatchFace {

    function initialize() {
    WatchFace.initialize();
    }

    // Load your resources here
    function onLayout(dc) {
    setLayout(Rez.Layouts.WatchFace(dc));
    }

    // Called when this View is brought to the foreground. Restore
    // the state of this View and prepare it to be shown. This includes
    // loading resources into memory.
    function onShow() {
    }

    // Update the view
    function onUpdate(dc) {
    // Get and show the current time
    var clockTime = Sys.getClockTime();
    var timeString = Lang.format("$1$:$2$", [clockTime.hour, clockTime.min.format("%02d")]);
    var view = View.findDrawableById("TimeLabel");
    view.setText(timeString);

    // Call the parent onUpdate function to redraw the layout
    View.onUpdate(dc);
    }

    // Called when this View is removed from the screen. Save the
    // state of this View here. This includes freeing resources from
    // memory.
    function onHide() {
    }

    // The user has just looked at their watch. Timers and animations may be started here.
    function onExitSleep() {
    }

    // Terminate any active timers and prepare for slow updates.
    function onEnterSleep() {
    }

    }


    Also I attached the actual prg file generated by my eclipse ( ), maybe something is wrong with it.
    I know, that the FR230 is one of the slowest IQ devices the only one being even slower is FR235, but, unfortunately, I can't afford to maintain many Garmin devices for pleasure of using them as test subjects.
    Thanks you for your time once again.
  • I tried the .prg in the .zip, and It switches in under a second, like I've seen with my own watchfaces.

    Have you tried powering off/on your watch? Maybe the "harder" power off, where you hold the light button even after you get the "power off" menu until the watch goes off by itself? (~15 seconds)
  • Former Member
    Former Member over 8 years ago
    I tried the .prg in the .zip, and It switches in under a second, like I've seen with my own watchfaces.

    Have you tried powering off/on your watch? Maybe the "harder" power off, where you hold the light button even after you get the "power off" menu until the watch goes off by itself? (~15 seconds)


    I did try the normal power off before, but "hard one" was new to me, nevertheless it didn't help: all of the watch faces except the one with an unexplainable "sweet spot" and the native one continue to lag on me.
    Maybe you can provide additional details on your FR230 before I try with the factory reset like: number of applications installed, number of development watch faces installed, free memory of an internal storage etc.
    Now you can understand that I feel puzzled, because I can't explain why some things work as expected and others don't or show strange behavior.
    And sorry, I didn't mention that my FR230 runs on lates available FW6.30.

    UPD. I did a factory reset, but still WFPerfTest being the only IQ watch face on watch gives me 2-3 second lag. If I build DigitalButterfly (sweet spot) even with the 2.2.1, then it switches instantly...
    Do you think that my device needs to be replaced (I bought it when it became available in my country, thus it may have some hardware quicrks common to first consignments) while it's still have some warranty left?
  • Former Member
    Former Member over 8 years ago
    I was able to identify source of the start lag: if there are "properties" in project, then application starts immediately, otherwise there's always a very noticeable 2-3 seconds slowdown, seems like the VM is either trying to search <app_name>.set file or to create one and stutters if there is no relevant definition. It's not necessary to create usable properties, even adding fake section like
    <properties>
    <property id="bc" type="number">0x000000</property>
    </properties>

    does the job. This properties related start lag can be seen not only with watch faces, but also with full scale applications and widgets as well. Good examples of such watch faces are ones created with an Android "FaceIt" Garmin application, some applications and watchfaces, which do not allow for a configuration can also be found on market. All of those I was able to test besides my own apps show the same behavior.


    Can someone from Garmin explain this?
    Thanks in advance.
  • I was able to identify source of the start lag: if there are "properties" in project, then application starts immediately, otherwise there's always a very noticeable 2-3 seconds slowdown, seems like the VM is either trying to search <app_name>.set file or to create one and stutters if there is no relevant definition. It's not necessary to create usable properties, even adding fake section like
    <properties>
    <property id="bc" type="number">0x000000</property>
    </properties>

    does the job. This properties related start lag can be seen not only with watch faces, but also with full scale applications and widgets as well. Good examples of such watch faces are ones created with an Android "FaceIt" Garmin application, some applications and watchfaces, which do not allow for a configuration can also be found on market. All of those I was able to test besides my own apps show the same behavior.


    Can someone from Garmin explain this?
    Thanks in advance.


    Thank you so much for sniffing this one out. This I have created a ticket to investigate and we will be looking at this as a team today.

    Thanks,
    -Coleman
  • Former Member
    Former Member over 8 years ago
    Great find easuvorov,

    I was able to trace down a bug that was causing the settings file to be deleted and regenerated every time an app was loaded if it was empty. A fix will get rolled out when devices release new updates with the next VM release.
  • Former Member
    Former Member over 8 years ago
    I was able to identify source of the start lag: if there are "properties" in project, then application starts immediately, otherwise there's always a very noticeable 2-3 seconds slowdown, seems like the VM is either trying to search <app_name>.set file or to create one and stutters if there is no relevant definition. It's not necessary to create usable properties, even adding fake section like
    <properties>
    <property id="bc" type="number">0x000000</property>
    </properties>

    does the job. This properties related start lag can be seen not only with watch faces, but also with full scale applications and widgets as well. Good examples of such watch faces are ones created with an Android "FaceIt" Garmin application, some applications and watchfaces, which do not allow for a configuration can also be found on market. All of those I was able to test besides my own apps show the same behavior.


    Can someone from Garmin explain this?
    Thanks in advance.


    Sorry, but could you please explain where you put the properties tag/content? I'm experiencing the same issue with my Forerunner 230, for a private (personal) watchface I created, and would like to fix it. Did you create a new file in the project in Eclipse, or did you add the tag to an already existing one?

    Much appreciated!
  • Sorry, but could you please explain where you put the properties tag/content?


    The properties go into a resource file (this is all something you can read about in the Programmer's Guide.
  • Former Member
    Former Member over 8 years ago
    The properties go into a resource file (this is all something you can read about in the Programmer's Guide.


    I got it to work, much appreciated!