POC - Combining BW Clock and Desktop Launcher to spend less time "Loading..."

[espruino-discuss2]

Posted at 2022-09-11 by @thyttan

Hi,

I'm testing to combine BW Clock and Desktop Launcher in one app to cut down the time switching between them.

To try it out:
EDIT 2: It's now possible to test it via my app loader here. Swipe left/right to move between BW Clock and Desktop Launcher, or use the physical button. The code is here.

I wanted to do this as a proof of concept of how loading times could be cut (I'd say dramatically) in some of the actions I do most often.

EDIT: Here's a video comparing loading times as described here.

Search tags: app switching, app loading, unload, unload().

---

Attachments:

• app.js

[espruino-discuss2]

Posted at 2022-09-12 by PeerDavid

Quite interesting -- do you have some measurements?

---

Posted at 2022-09-12 by @thyttan

Moving from clock to launcher feels instant. Moving from launcher to clock feels like it takes 0.5-1 second. For me going either direction usually takes 2-2.5 seconds, counting in my head - very scientific 😅😋

---

Posted at 2022-09-12 by @gfwilliams

I can't seem to make it work with switching between clock and launcher if just installing via app loader.

What doesn't work that you expect to work?

I'd be really interested to hear timings too - it can have a reasonably big effect not having to reload everything between apps, but it does need the apps to be built in such a way that it can be done (eg allowing themselves to be 'unloaded', and having all apps use widgets) or you'll end up with memory leaks or strange behaviour...

Rather than building apps together, there would be ways to do this directly. For instance an app could define an unload function. And if that function existed then Bangle.showLauncher() could just call unload() and then load up the launcher without going through the whole reset process.

---

Posted at 2022-09-12 by @thyttan

What doesn't work that you expect to work?

If I install via the app loader I'm not able to swipe left/right to move back and forth between clock and launcher, but when uploading via web ide I am. (It never works when opening it from my usual launcher, even when having overwritten the app code via the web ide)

EDIT:

I'd be really interested to hear timings too

I recorded a video (attached) of me:

1. uploading the clocknlauncher app.js-code to clocknlaunch.app.js via app loader.
2. swiping to move between clock and launcher.
3. Long pressing physical button to load the original BW Clock.
4. Pressing physical button to load Desktop Launcher and BW Clock respectively.

Btw, I'm in favor of the unload functionality you propose if it's not self evident (without completely understanding it :p). Could there be a variable you set in Bangle.setUI() similar to how "clock : 1" is set, so maybe "unload : 1", to indicate the app is "unload-compatible"? This way it would not be mandatory to update every app (?!) for them to continue working even after adding "unload-functionality"...

---

Attachments:

• Clocknlauncher_load_time_comparison.mp4

---

Posted at 2022-09-13 by @gfwilliams

Wow, yes - that's a big improvement!

It's a good point about setUI - that could be a much cleaner way of handling it than just checking for a global function in showLauncher. Either way it would be pretty straightforward to just default to calling load if there was no 'unload' function.

About the swipe not working: do you see any errors when you connect with the IDE? I guess it could be related to minification messing the code up somehow?

---

Posted at 2022-09-13 by @thyttan

About the swipe not working: do you see any errors when you connect with the IDE? I guess it could be related to minification messing the code up somehow?

No error messages except for "error: No http method found" (which I see on most loads for most apps). I've tried toggling pretokenization on the app loader before upload.

Also, when setting minification options to "Simple Optimizations", or "Esprima", (also for modules) and turning on pretokenization for the web ide, swiping still works after uploading the code that way. "Advanced optimizations" don't work at all.

---

Posted at 2022-09-14 by @gfwilliams

No error messages except for "error: No http method found" (which I see on most loads for most apps). I've tried toggling pretokenization on the app loader before upload.

Hmm - this must be some code you've got using http accesses, when it should use Bangle.http or maybe you just need Gadgetbridge installed? Do you get any clue what file the error is in?

I guess maybe the error is actually stopping execution of some code which comes after it, and that could be causing your problems?

---

Posted at 2022-09-14 by @thyttan

Ok, will do a backup and factory reset and try clocknlauncher after that and see if swiping works then. 👍

I have a nightly of Gadgetbridge Bangle.js flavor installed which I have built myself with the most recent changes to the intents-functionality that's yet to be merged to the main project (although it's name on the phone is "Gadgetbridge (nightly)" instead of "Bangle.js Gadgetbridge (nightly)").

Don't know right now what file the http-error is in.

---

Posted at 2022-09-14 by @thyttan

I tried a factory reset and installed clocknlauncher with the same result as earlier with not being able to swipe between clock and launcher. I then tried flashing latest cutting edge firmware 2v15.14 with no change either. Still works if I upload via the Web IDE. The http-error is gone after the factory reset.

EDIT:

I had A-GPS Data installed. After removing it the http-error disappeared.

---

Posted at 2022-09-15 by @thyttan

I set another clock as my default one. This led me to realize that what happens when I try to open 'clocknlauncher' via my regular launcher is that my currently selected clock (in Settings app) is loaded. Don't understand why that is though. The code is 1106 lines long, can that be a problem? But why does it work via the Web IDE in that case? Also, it's not that much longer than just the BW Clock-code.

---

Posted at 2022-09-16 by @thyttan

I got this as a build error on github earlier.

build: apps/clocknlauncher/metadata.json#L1
App clocknlauncher has no entrypoint

Is that a hint about my problem?

---

Posted at 2022-09-16 by @thyttan

I got it working now. Kind of embarrassing, I hadn't made sure id and filenames in storage matched... Sorry about that 😅.

It's now possible to test it directly via my app loader here.

Edit: The code is here.

---

Posted at 2022-09-22 by @thyttan

@gfwilliams How prioritized would you say implementing something like unload() is? Do you want to implement it yourself or rather have someone else do a PR?

Personally it feels a bit out of my depth but I do think it would be very beneficial for everyone with a Bangle as well as for making the watch even more appealing to potential customers.

Also, do you think it can be as quick as what've been demonstrated with combining the apps here? or will it sit somewhere between load() and merging apps?

---

Posted at 2022-09-23 by @gfwilliams

It's not super high priority for me because there's a high likelihood it'll affect stability (all it takes is a clock author not managing to free all memory in the unload function and the clock will break after a few trips to the launcher).

However, I have made some changes in the latest cutting edge builds. There was already a Bangle.uiRemove handler so I've hooked onto that, and I've updated Antonclock and the launcher in the development app loader. If you run the latest firmware with those, you should see a pretty fast flip between the launcher and back.

It's not as fast as if the two apps were integrated (because then you could have pre-loaded the apps list) but it's not that bad.

---

Posted at 2022-09-23 by @thyttan

Cool, will check the latest cutting edge build out! 👍 Thank you for that and for the clarifications 🙂

---

Posted at 2022-09-26 by @thyttan

That solution works quite well - nice one! I have been trying to imitate that remove-functionality to latest versions of Desktop Launcher and BW Clock but haven't got it working as smooth as you did with Anton Clock and Launcher. Two main problems I had so far is (1) having it work together with code that imports other modules (e.g. clock_info in this case), and (2) I get ram filling up slowly when switching between clock and launcher - as you anticipated 😅. I think the ram-issue is related to Desktop Launcher's app list but I'm not sure. There are also some other small quirks I will not detail now. I attached the app codes with my changes to this comment.

Thinking out loud: Could an alternative to manually merging apps be to use the require-function? So similarly to how clocks now can require clock_info they could also require the installed launcher which then is merged in with the clock app code while loading the clock from the app loader. I haven't read up on this or tested it yet.

---

Attachments:

• dtlaunch.app.js
• bwclk.app.js

---

Posted at 2022-09-27 by @halemmerich

This is absolutely awesome. I had to try with Imageclock and Iconlaunch and hacked some things together to make it somewhat work with this new mechanism.
Cleanup is not yet complete, Imageclock uses a lot of timeouts and intervals and sometimes still comes back over the launcher, but the fast switch between launcher and clock is great. Drawing the widgets also does not yet work correctly.
I think the next question is how to check during development that nothing is left over ;)

Edit: Got it mostly working now. There seems to be some state left with regard to the widgets which causes them not to be rendered after switching back and forth with them visible. The rest seems to be working pretty well.
https://github.com/halemmerich/BangleApps/tree/unload

---

Attachments:

• VID_20220927_192127.mkv
• VID_20220927_192300.mkv

---

Posted at 2022-09-28 by @gfwilliams

(1) having it work together with code that imports other modules (e.g. clock_info in this case)

Yes... Modules like that will end up staying in RAM. BUT they will only be loaded once, so they're not going to end up using more and more RAM each time. If the module is designed well it shouldn't actually use up too many vars (less than 20) so I wouldn't worry too much about those.

There seems to be some state left with regard to the widgets which causes them not to be rendered after switching back and forth with them visible

This really only makes sense if the widgets are kept visible on both cases. If you have to remove them then every widget would have to support unloading too - and also reloading them will add to the time required to change apps, so it's less of a win.

Otherwise the widgets should still be fine I think...

---

Posted at 2022-09-28 by @halemmerich

Actually I got the widgets to render and behave mostly as expected. There is still something strange going on. Imageclock always loads the widgets and then replaces the draw functions with functions doing nothing and restores them as needed (showing the widgets/switching to launcher). Essentially that hinges on a showWidgets variable, which should be false on every initialization, but the widgets visibility survives the switch between clock and launcher. Widgets shown on clock are still shown after switching to launcher and back.
I would expect the showWidgets variable to be removed and reinitialized to false, since it lives in the block scope. The memory after GC is always the same for launcher and clock, so probably no major leaks. Launcher uses less memory than clock, as expected.
The behaviour is actually quite nice, but I don't understand why it works that way. Printing the showWidgets variable at the top of the block does not work, as it is not yet defined.

---

Posted at 2022-09-29 by @gfwilliams

Imageclock always loads the widgets and then replaces the draw functions with functions doing nothing and restores them as needed

Ahh, yes, that'd do it! That would all need undoing... It's the kind of thing that (IMO) we should turn into a library and then maybe the library could handle it automatically.

---

Posted at 2022-09-29 by Sir_Indy

Would this be a good time to mention the Hidable Widget Bar? I haven't tried it with this fast app switching yet, but I can't see why it wouldn't work.
Would it be helpful to add some settings? Always Show Widgets, Always Hide Widgets, Swipe to show or hide? Or pick a gesture to show and hide? I have no idea how to make it a library though!

---

Posted at 2022-09-29 by @halemmerich

This seems very cool. Does this clash with other apps using the setLCDOverlay or would the widgets just no longer be displayed if for example another app shows notification with this method?

---

Posted at 2022-09-30 by @gfwilliams

Yes, the hideable widget bar is exactly the kind of thing we need. It could be added to https://github.com/espruino/BangleApps/tree/master/modules and required...

Does this clash with other apps using the setLCDOverlay or would the widgets just no longer be displayed if for example another app shows notification with this method?

Yes, it's just be the last call to setLCDOverlay. Hopefully after a while the widget bar would auto-hide and things would reset though

---

Posted at 2022-10-04 by @halemmerich

I have tried your code @Sir_Indy with Imageclock and Iconlauncher and like it a lot. Much better than my own swiping-to-show-widgets hack.
Some things still to consider:
setUI currently does not clean up the Bangle.CLOCK marker variable, so Bangle.CLOCK stays once there was a setUI with a clock mode.
Just deleting this in setUI does not solve the problem though, since there are widgets, that differentiate their behaviour during loadWidgets. An example would be the widclk, which just does nothing in case of Bangle.CLOCK.

I have done the change to delete Bangle.CLOCK in the Espruino repo, but could not find documentation on how to create the minimized variants of the scripts.

Those widgets need some kind of way to be selectively reloaded on change of Bangle.CLOCK.
Some ideas of the top of my head:

1. Remove the check and once again load all widgets on every call to loadWidgets. Slow and not great, but easy and backwards compatible.
2. Change widgets using this style to check during draw for Bangle.CLOCK and just hide themselves on clocks. Fast, but uses more memory on clocks since the widget will be loaded.
   2b. Have widgets have an update method to be called by setUI if available to notify them to check for changes as Bangle.CLOCK.
3. Somehow identify widgets not used on clocks during the initial load. Then after change of Bangle.CLOCK load only the missing widgets during loadWidgets. Maybe widgets could be un/loaded depending on some metadata.json entry to match the current Bangle.CLOCK state?

---

Posted at 2022-10-14 by @thyttan

Thinking out loud again: If unloading/eval becomes more common should the unloading function of apps be exported and be accessible by other apps? This way e.g. Quick Launcher or Pattern Launcher could utilize/facilitate faster app switching as well?

I've nearly got remove/unload and eval working between BWClock and Desktop Launcher correctly on my app loader now. There's still some small buildup in RAM usage though.

EDIT: BWClock code. Desktop Launcher code.

---

Posted at 2022-10-15 by @halemmerich

I think as a first step the implementation as a remove handler set for setUI is probably enough. It should be possible for apps like quicklaunch to just call setUI() to trigger the removal of the currently running main app.

I did a small demonstration of the combination of UI removal, @Sir_Indy s hidable widget bar, modified gpstrek/iconlaunch apps and widgets implementing an update method. This may be the loading-screen-less future ;)

Not yet bug free, far from optimal but very cool to see the Bangle be about as fast as my old Amazfit BIP S.

---

Attachments:

• VID_20221015_202104.m4v

---

Posted at 2022-10-15 by @thyttan

That makes sense. Nice demo! :) The Bip is in the back of my mind as well ;)

---

Posted at 2022-10-17 by @gfwilliams

I think setUI is probably enough for now too.

It's worth adding though that while this is cool - I really don't think we should rush to implement this all over the place (particularly app switching). The benefits of saving ~0.5 sec changing apps would be easily wiped out if it in any way caused the watch to become unstable

---

Posted at 2022-10-17 by @thyttan

...The benefits of saving ~0.5 sec changing apps would be easily wiped out...

Yes, from my own tests not entirely managing to mitigate buildup in RAM use I absolutely see your point. But I am eager to have my bangle be faster with app switching in particular 😛 that's really the one area where it feels slow - within apps it's plenty responsive for my tastes.

What do you think of the route taken with the latest update to Icon Launcher where there's now the option to switch "fast app loading/switching" on in settings? Is it safeguard enough to have the default be regular load()-calls with the option of faster/likely less stable eval()-calls also for more apps? Or do you feel this could be more trouble than benefit as well? 🙂

---

Posted at 2022-10-17 by @gfwilliams

Yes, from my own tests not entirely managing to mitigate buildup in RAM

If we actually know it doesn't unload completely and will cause instability eventually, I'm a bit unsure about it even being in the default Icon Launcher behind an option. Of course if you want to do it in your own copy of the app loader then that's great - but I'd much rather that anyone interested tries it out there knowing what they're letting themselves in for, than a normal user turns the option on without really understanding what the implications are (if you see an option titled 'fast launch' you're probably going to turn it on).

Personally, I feel like there are a few other ways to improve experience, like switching to using the on-chip flash memory access hardware (currently we just use software). I'd much rather get stuff like that done and improve performance across the board than spending time trying to work around it.

should the unloading function of apps be exported and be accessible by other apps? This way e.g. Quick Launcher or Pattern Launcher could utilize/facilitate faster app switching as well?

The issue here is it's not just clock -> launcher -> app but maybe clock -> launcher -> app -> app -> app -> app -> etc and so any leaks will really add up.

These kind of things would work great in a controlled environment, but Bangle.js App Loader is anything but a controlled environment. Code quality of apps on average isn't great as-is, and I honestly don't ever see a point where we could happily say that every app will clean up after itself.

... and even if we tagged apps that did clean up after themselves, I think it's unlikely that each contribution to an app in the future would be checked to see that it didn't leave memory behind.

---

Posted at 2022-10-17 by @thyttan

All good points, especially about prioritizing doing things 'right' instead of having workarounds if they aren't needed. Thanks for elaborating.

If we actually know it doesn't unload completely and will cause instability eventually, I'm a bit unsure about it even being in the default Icon Launcher behind an option.

'My tests' referred to the modified BW Clock and Desktop Launcher on my app loader. I haven't tested Icon Launcher for RAM use buildup - but I suspect @halemmerich has done a better job with that than I have with my tests ;)

And again, I can just look to my own code and ability to understand retaining stability is a real issue.

---

Posted at 2022-10-17 by @halemmerich

I too would prefer @gfwilliams s resources to be spend on improving system wide performance. There are lots more people doing experimentation on the JS side of things than on firmware level.

My daily driver bangle install currently needs 1.6s of time between the first line of .boot and the first line of the default launched clock after reboot. Switching from clock to launcher currently needs 3.83 seconds for me, which feels like a LOT. It is actually the most remarked on thing if I show the bangle to other people. Fastloading reduces this to basically nothing in case of apps without significant own loading times. Worst offender beeing imageclock adding at least a few hundred ms to those nearly four seconds ;)

I created my fair share of memory leaking boot code, so the problem generally is not a new one :)

The problem for fastloading can be split in a few parts. Some are not as critical for memory leaks.

Clock <-> Launcher: Should be relatively easy to check for memory leaks during development and is one of the most done transitions. This works well on current firmware with setUI-remove and the eval style of loading the clock.

Launcher -> App: The only point that should not be leaking memory is the launcher, since it needs to remove itself to free up memory for the app. The app should not see any difference to beeing loaded after the normal boot code then.

App -> Launcher/Clock: Technically the same as launcher to app, but a lot more apps to check and validate. Modification of all apps and keeping them clean in regard of memory use is not really feasible. Current state of affairs is a reboot of the system if no remove-method is implemented. This also mitigates smaller leaks by rebooting every few app launches. This waiting time is not really a problem, since closing an app often means stopping use of the watch anyway. At least for me the delay after using an app is a lot less impactful than the waiting for an app to open.

Widgets: This one is currently not that easy to solve. I have experimented with tracking which listeners and timeouts etc. a widget registers, but trying to clean that up later opens a whole can of worms that probably better stays closed (think reused timeout numbers).

I think some change in handling the widgets would be nice, maybe returning the widget as an object from the wid.js with some conventions on how to structure them could work well (a bit like the recorder modules are loaded and added). This would also allow to return a stub object that loads the widgets code from a file on first call to keep the memory use minimal in case an app does not loadWidgets. This would solve some things like the widget name not matching the file name or widget JS loading no or more than one widget on some condition (not easily recoverable from if widgets are not filterable for this behaviour).

My current experiments include a fastload-app, which modifies the Bangle object to add some handling for unloading widgets and additionally widgets need to implement a remove method to properly work (at least those that use timeouts/listeners etc.). An optional update method is used for notifying widgets of changes like Bangle.CLOCK.
This seems to work well for apps with and without widgets. Could be more efficient, since it effectively hard unloads and later reloads all widgets if an app does not call loadWidgets immediately. There is of course the problem of not (yet) modified widgets, but this could be handled by disabling fastload in this style if one of those is loaded. I'm sure there are still lots of edge case that I have not yet triggered.
Main magic hides here: fastload.boot.js

Current state of experimentation in my apploader:
Firmware: at least 2v15.20
Clock: Anton
Fastload enabler:
fastload
Modifed for fastloading:
iconlaunch
gpstrek
widclk
widbat
widlock
widbars
widcloselaunch

Not really needed for fast loading but very nice effect:
@Sir_Indy s slightly modified widhide for swiping the widget bar from the top on clocks.

But all of this might well be a case of:

---

Posted at 2022-10-18 by @gfwilliams

Switching from clock to launcher currently needs 3.83 seconds for me, which feels like a LOT.

Ouch - yes! I'd be really interested if you could figure out what's taking the time there.

But yes, I think the clock -> launcher transition is one where it does make sense to try and avoid the load(). Even if there are leaks at least it only happens once at the moment so won't cause a huge build-up.

With widgets: loading these can take a decent amount of time, and personally I think trying to handle loading/unloading them automatically when switching apps is just a step too far. If you're not careful you end up doing so much extra work that even after all this, load times will not be significantly better than if you just did load()

---

Posted at 2022-10-18 by @halemmerich

My tests with implementing a remove method on widgets work well but would need implementation in all widgets. Maybe an alternative to this would be keeping the widgets loaded, but hiding them in apps not loading widgets? RAM could be an issue, but at least on bangle 2 it seems to be not that problematic for most apps.
A lot easier to implement and probably all of it in a bit of boot code. Actually really similar to what widhide does right now.

As far as the starting time goes, the biggest block is the quicklaunch app at about half a second for scanning the 40+ apps I have installed. The rest is not that big, but there are some apps that need a bit more time. Sensor tools and BTHRM have a lot of code. I do not know where the 2.23 seconds not explained by the 1.6 seconds from .boot are from. There could be some time from initial drawing and loading widgets for the launcher in there. I timed from the first frame showing the loading screen to the icons from iconlauncher showing.

---

Posted at 2022-10-19 by rigrig

Maybe an alternative to this would be keeping the widgets loaded, but hiding them in apps not loading widgets? RAM could be an issue,

How many apps don't load widgets, and why? It might be best to just slow-load() those apps.
I can't think of a good way to determine if an app is going to load widgets though :-(

scanning the 40+ apps I have installed.

It looks like quicklaunch could be improved a bit to not do this every boot, but just check if an app exists before loading it.

Maybe we should add a debug bootloader that logs per-bootfile timings to the console on boot?

---

Posted at 2022-10-19 by @gfwilliams

Maybe an alternative to this would be keeping the widgets loaded, but hiding them in apps not loading widgets?

Yes, I think that would be best - if it were implemented in a library it should be pretty easy to include.

Wrt timings:

• As far as I can see quicklaunch really has no need to load the whole apps list at boot. It might as well just check that appname.info exists when it's time to load the app.
• BTHRM is huge and I imagine just parsing that takes a while - there was some talk of trying to strip down what goes into the boot code (or maybe resurrecting the old one as a lite version? the original has 70 lines of boot code, not 630).
• I just looked, and again sensortools is another 350 lines of boot code so that won't be quick either.
• You say you're timing to iconlaunch displaying? If quicklaunch is that slow then I guess iconlaunch loading every app's icon file before it displays everything (launcher does this too though) could really slow it down. How many apps do you have?

I suppose it could be an option to extend the bootloader code such that there was an option to show the load times of each section?

I think my concern is your watch is slow because there's a huge amount of extra stuff that's been added to it. Personally, I feel like rather than adding more code to try and work around that, it'd be best to work on finding out what's slow and then optimising those bits, because I think there's some really low hanging fruit there.

For instance if the launcher is slow, potentially there might be a way of pre-parsing all the apps into a single JSON file (much like the bootloader adds everything to one file and uses .hash to check for changes). Icons could also be loaded as-needed since you only need to load the first 9 before you display the first page of the icon launcher?

I'd have thought that with a bit of work between the various apps/widgets/boot code you could maybe even double boot speed, and that would then apply to everything

---

Posted at 2022-10-19 by Serj

My 2 cents: It would be great if the launcher and app loading times could be reduced. At the moment, a long time Loading ... most annoying in daily use.

---

Posted at 2022-10-19 by @gfwilliams

I just pushed some changes to the development app loader to enable an app cache in the default launcher.

• In a default-ish install it brings the startup time down from 0.46s to 0.36s
• I installed a few extra apps and it came down from 0.57s to 0.39s (it scales much better)

And if you're switching apps so not reloading widgets it's even faster (0.25s). I feel like the same changes could be pulled into other launchers pretty easily too, and would go a long way towards improving the app switching times when there are a lot of apps installed.

Maybe we should add a debug bootloader that logs per-bootfile timings to the console on boot?

Try this: https://gist.github.com/gfwilliams/95f776176929b58b3603034065c3ec2d

Seems to work ok, by default I'm seeing:

init 0.06207275390
health.boot.js 0.01016235351
sched.boot.js 0.01272583007
welcome.boot.js 0.00277709960

So not too bad at all.

---

Posted at 2022-10-19 by @halemmerich

Loading the widgets and manipulating the loadWidgets/drawWidgets/draw-methods to just do nothing in case an app has not loaded widgets seems to work a treat. I believe the only way for widgets to disturb graphics is now drawing outside of the draw method. This could be handled by giving the widgets a dedicated buffer like widhide does.

I have implemented some changes for logging boot times:

Boot times:
  sensortools.0.boot.js: 302ms
  bthrm.0.boot.js: 151ms
  agpsdata.boot.js: 14ms
  android.boot.js: 61ms
  calibration.boot.js: 17ms
  fastload.boot.js: 17ms
  health.boot.js: 44ms
  owmweather.boot.js: 68ms
  qmsched.boot.js: 24ms
  quicklaunch.boot.js: 622ms
  sched.boot.js: 49ms
  swscroll.boot.js: 11ms
Boot took 1592ms

So actually BTHRM is not even that bad ;)
Sensortools is easy to fix, just moving everything into a lib and requiring only if enabled should help. BTHRM not that easy, tried 2 times now and did not manage meaningful size reduction without losing features I want. Quicklaunch is probably easy to fix as @rigrig said.
Iconlauncher takes about a second to load on my 40 app bangle, probably relatively easy to alleviate that by loading apps/icons as needed instead of all at once as you suggested.

But, currently I can with very little effort remove these 1.6 seconds altogether by just not needing to execute the boot files between app changes (or at least from launcher to app). Besides that I think optimizing single apps is currently more important than fastloading, even if I personally like the efficiency of not tearing down the environment for every app change. That will probably bring down the time to around half a second on a big install like mine. Probably good enough for most usecases.

Comparison between nearly empty bangle on 2v15 without fastloading and 2v15.40 with fastloading shows a nearly halved time from clock to launcher and about 10% faster the other way round (Anton and Launch). Although in this setting both seem to be very similar to the naked eye.
Espruino itself seems to take roundabout 80ms between load() and the first line of .boot0

There remains one point where fastloading has a real benefit:
Not losing state in BT and sensor stuff. Reconnecting in BTHRM takes some time and I think keeping a gps fix alive is also beneficial in comparison to aquiring it new on every app change. If I use GPS I currently think twice about changing the app as not to loose a fix which I then sometimes can not get back.

I will keep playing around with the fastboot idea in my apploader and try to get some PR in for low hanging fruit :)

---

Posted at 2022-10-20 by @halemmerich

I took your caching code and integrated that into iconlaunch. Updating the cache takes about 1.5s while using the cache "only" needs 500ms. Pretty awesome improvement, would not have expected this.

Finding the launcher every time is also slow. I have implemented something similar to what is done for clocks with the possibility to configure one in the settings. That takes the time for finding the launcher from 194ms down to 7ms on my close to stock bangle. Probably a lot more on the other one.

---

Posted at 2022-10-21 by @gfwilliams

Thanks! Just merged (and also merged your similar changes for the clock) and the builds now with up to date JS really do feel a lot snappier.

Now we just need to ensure that more clocks implement Bangle.setUI({..., remove}) - just a note that I tried adding it to the ClockFace module but clocks like terminalclock add a lot of other stuff which caused it to break. I guess we could make it opt-in

---

Posted at 2022-10-23 by @halemmerich

There remains one small thing to get the current state working correctly with regard to widgets.
Currently some widgets prevent themselves from being loaded depending on Bangle.CLOCK.
I have checked and only found widclk,widclkbttm,widclose and widcloselaunch to have this problem. We could solve this by just checking Bangle.CLOCK on every draw and react accordingly or we could define widgets to have an update method to tell them to recheck their environment.
Implementation on the Bangle side of things could be done by calling all available update methods on widgets at the end of Bangle.setUI and Bangle.loadWidgets. Update method is better when widgets change their width depending on CLOCK and prevents additional calls to drawWidgets which would be needed when draw changes the width.

The small negative impact of this would be loading the 4 mentioned widgets even if a clock app is active. Since they are all on the order of 10 lines of code this is probably not a problem. Solving the problem for theoretical future big widgets would be possible by having the update method un/load the big pieces of code on demand.

I have tried the update method way and have not found any problems with it the last few days.

---

Posted at 2022-10-26 by @gfwilliams

The update method sounds good to me (I'm not sure if we could document that anywhere?). Or given the relatively few widgets that do this, we could just check in the draw method and then queue a call to drawWidgets if it changed?

if ((Bangle.CLOCK==true) != (WIDGETS.widclk.width==0)) {
  WIDGETS.widclk.width = Bangle.CLOCK? 52 : 0; 
  return setTimeout(Bangle.drawWidgets,0);
}

I seem to recall there are some widgets that do similar things already.

Using extra RAM is a bit of a shame on Bangle.js 1 but I guess it's not much - and actually adding an update method would be worse than the above

---

Posted at 2022-10-26 by @halemmerich

Every widget that changes it's width during draw needs to schedule a redraw. This seems somewhat wasteful since at least with simple timeouts all calls will eventually be executed. The update methods can all be called without needing to schedule additional draws. Drawing in that case only needs to be done if an app actually calls drawWidgets.

The current state of affairs is at https://github.com/halemmerich/BangleApps/tree/experimental/widgetUpdate and my apploader at https://halemmerich.github.io/BangleApps/

There are now two apps that should work indepent from each other: fastload and widgetupdate

fastload mostly wraps load to automatically decide between reboot and fast loading. That keeps the apps a tiny bit simpler. The rest just basically wraps methods to be able to show a different loading screen and add handling remove-methods in the E.show* methods. This will probably stay an app on my apploader for the foreseeable future and I suspect to have missed a lot of edgecases.

widgetupdate is a bit more interesting as it handles the hiding of widgets (including wrapping touch,drag and swipe handlers) as well as setting a correct appRect and detection of an app loading widgets or not. That should work for all apps without changes in the app. This also does essentially the same thing for the drawing as the newest widget_utils module does but at widget loading time. Newly available methods are Bangle.updateWidgets() and Bangle.hideWidgets().

There also is a small modification in bootloader which adds Bangle.showClock. That is used in widclose and launch to get the clock loaded while beeing able to be modified by fastload if installed. Essentially this prevents using eval there, which can not be overriden to modify its behaviour. It always calls load, which is then optionally overriden by fastload with the eval approach depending on the existence of Bangle.uiRemove.

Maybe some of the widget handling could be integrated into the firmware to fix the current bad behaviour with regard to Bangle.CLOCK changes.

Alternatively the fast loading using eval from clock to launcher could be reverted to get the widgets working like they were before and then optionally reinstated by installing fastload and/or widgetupdate. That would however mean implementing remove handlers in watchfaces/apps and update methods in widgets that are not used if those two apps are not installed.

TL;DR: To try it out install bleeding edge firmware, install fastload and widgetupdate ,update everything my apploader has newer versions of and probably expect bugs (especially messages is currently practically not tested at all) :)

---

Posted at 2022-10-26 by @thyttan

I gave it a spin! A video of me navigating the watch with presses of the physical buton, then using Quick launch, and doing some other stuff, is attached.

It's a bit inconsistent with it sometimes displaying 'load' message, sometimes 'fastload' message and sometimes no message box. The most consistently inconsistent (😛) thing with regard to this is when I go back and forth between clock and launcher using the Quick launch app for swipes.

I also noticed that if I had 'Widget editor' installed the widgets would not be rendered graphically, but could be pressed (e.g. back button).

Used both fastload helper and widgetupdate.

---

Attachments:

• VID_20221027_010750.mp4

---

Posted at 2022-10-27 by @halemmerich

Spotify remote does not implement a remove handler for setUI so normal loading is expected. Quicklaunch replaces the setUI function on clock faces and when fastloading to somewhere else that is not cleaned up until a normal load. That is probably the reason for changing behaviour.
Widget editor throws the loaded and modified widgets away and reloads everything manually. That probably creates problems with the wrapped draw methods. There should be a way to resort the existing widgets objects to prevent that.

It seems there are still some things to catch :)
I have today seen a problem where menus are functional, but sometimes not updating the display correctly. It seems there is one draw on tap missing. Scrolling up and down then shows correct content.

Edit: D'oh! Forgot to return the resulting object when wrapping E.show*, will fix that this evening.

---

Posted at 2022-10-27 by @gfwilliams

I think there's a bit of a worry with what you're doing with E.showMenu/etc. For a simple app that just shows the menu it's fine, but imagine something like https://banglejs.com/apps/?id=espruinoterm where it's done something (opened a bluetooth connection in this case) and then shown a menu. Now when you want to switch apps you'll just move right on to the next app without clearing up.

This looks great as a proof of concept and it's really cool to have it on https://halemmerich.github.io/BangleApps/ for everyone to use if they want to, but just to warn you that I think right now this is just too much to try and merge back into the default app loader.

Even the changes to individual apps to make them compatible can be bad. For instance I just checked the messages app...

• Default messages app -> loads in 248ms
• messages app wrapped in (()=>{ ... })() -> 370ms
• messages app wrapped in ()=>{ ... }() as done here -> 420ms (it's not valid JS so can't be minified)

The reason is when you just have the app on its own, it can be executed in one pass straight from flash. But when you wrap it in a function the whole function has to be parsed from flash and then read again a second time when it's executed.

If the function wrapping is to stop functions getting defined outside of scope, I think changing: function myfun(...) { ... } to let myfun = function(...) { ... } should have the desired effect.

I'm all for making Bangle.js faster, but I don't want to be in the position where I'm making it slower for everyone else just so that it can be faster for those that choose to install fastload.

---

Posted at 2022-10-27 by @halemmerich

I think there's a bit of a worry with what you're doing with E.showMenu/etc. For a simple app that just shows the menu it's fine, but imagine something like https://banglejs.com/apps/?id=espruinote­rm where it's done something (opened a bluetooth connection in this case) and then shown a menu. Now when you want to switch apps you'll just move right on to the next app without clearing up.

That is why I tried to add the remove handler to the options given to E.show*. Apps then can cleanup after themselves if I decide to leave them when they are in a menu. The default is still not cleaning up and loading normally. See setting a remove handler for the scroller in launch to make fastloading out of it possible halemmerich/BangleApps@74d0499.

This looks great as a proof of concept and it's really cool to have it on https://halemmerich.github.io/BangleApps­/ for everyone to use if they want to, but just to warn you that I think right now this is just too much to try and merge back into the default app loader.

I think we need at least a solution for the widgets not beeing updated correctly either in draw methods (multiple calls to Bangle.drawWidgets() => slow) or with update-methods in Firmware (part of what widgetupdate does). The rest I am completely fine with keeping separate.

For instance I just checked the messages app...

You can completely ignore that, there I just tried to have a look at how far I could go without completely borking everything. I will probably revert that completely since it is massively complex to even test every feature. Preferred solution to that would be an alternative implementation like is discussed in https://forum.espruino.com/conversations/375794/.

If the function wrapping is to stop functions getting defined outside of scope, I think changing: function myfun(...) { ... } to let myfun = function(...) { ... } should have the desired effect.

Yes, tried that for some apps and works fine. Didn't think about the code reading/parsing implications of wrapping in a function.

I'm all for making Bangle.js faster, but I don't want to be in the position where I'm making it slower for everyone else just so that it can be faster for those that choose to install fastload.

No, fastload must be optional and as free of changes for all other stuff as possible. In the end normal loading will probably be the default for a long time. But stuff similar to fastloading will happen inside of apps (showing menus, scrollers and using setUI() for different parts of the app etc.) and I think we should have working cleanup for those scenarios.

---

Posted at 2022-10-27 by @halemmerich

I have done some changes to quicklaunch and wid_edit. Those should help with the erratic behaviour. I had not yet used wid_edit before, but I think it still works.

---

Posted at 2022-10-28 by @gfwilliams

That is why I tried to add the remove handler to the options given to E.show

Ahh, thanks! Sorry, I missed that. That could be a good change to pull into the main Espruino versions and will be backwards compatible.

I think we need at least a solution for the widgets not beeing updated correctly either in draw methods (multiple calls to Bangle.drawWidgets() => slow)

How slow is it really though? I just tested here and I get 70ms for a full widget redraw (which will only happen when apps are swapped from clock->something else or back). But because it's executed in a timeout, the app will load, everything will display fine and then the widget redraw will happen - so it's not going add a noticeable delay to loading.

I'm just conscious that this is for 4 widgets (widclk,widclkbttm,widclose and widcloselaunch), two of which are basically forks, so really only 2 widgets (neither of which are super popular). I wonder how much effort we really need to put into saving that extra 70ms that won't be noticed anyway.

widgetupdate is interesting, but by wrapping every widget draw function with a check it is adding several ms of overhead to every draw call (and memory use). Also previously appRect was dynamic (if you had a widget that updated itself to appear or disappear, appRect could change over time).

I guess one option is to modify drawWidgets at https://github.com/espruino/Espruino/blob/master/libs/js/banglejs/Bangle_drawWidgets_Q3.js#L11 to add if (wd.update) wd.update();

So then if a widget needed to change its size (or area), it could do it on the next drawWidgets call without having to reschedule a whole new draw. That'd add maybe a ms or two to drawWidgets but in total it's pretty tiny.

Didn't think about the code reading/parsing implications of wrapping in a function.

Yes, I only really noticed it recently. It's a shame there's not a better way around it.

stuff similar to fastloading will happen inside of apps (showing menus, scrollers and using setUI() for different parts of the app etc.) and I think we should have working cleanup for those scenarios.

Yes, absolutely!

---

Posted at 2022-10-28 by @thyttan

I get this after I install widgetupdate on a fresh install:

>OK
OK
OK
Uncaught Error: Cannot read property 'filter' of undefined
 at line 1 col 112 in messages.wid.js
msgs.filter(msg=>msg.new&&msg.id!="music").map(m=>m.src).filter((m...
          ^
in function "filterMessages" called from line 1 col 1371 in messages.wid.js
...msgs=filterMessages(rawMsgs);this.width=24*E.clip(this.msgs.length...
                                    ^
in function "update" called from line 16 col 329 in .boot0
...ETS[i];if(w.update)w.update();}}
                               ^
in function "updateWidgets" called from line 16 col 1049 in .boot0
...};});}Bangle.updateWidgets();if(!WIDGETS_LOADED)WIDGETS_LOADE...
                               ^
in function "o" called from line 35 col 29 in .boot0
o();const s=require("Storage").readJSON("wid_edit.json",1)||{};const c=...
             ^
in function "loadWidgets" called from line 3 col 7789 in antonclk.app.js
...all;}});Bangle.loadWidgets();Bangle.drawWidgets();}
                              ^
>
Uncaught Error: Cannot read property 'filter' of undefined
 at line 1 col 112 in messages.wid.js
msgs.filter(msg=>msg.new&&msg.id!="music").map(m=>m.src).filter((m...
          ^
in function "filterMessages" called from line 1 col 1371 in messages.wid.js
...msgs=filterMessages(rawMsgs);this.width=24*E.clip(this.msgs.length...
                                    ^
in function "update" called from line 16 col 329 in .boot0
...ETS[i];if(w.update)w.update();}}
                               ^
in function "updateWidgets" called from line 16 col 1049 in .boot0
...};});}Bangle.updateWidgets();if(!WIDGETS_LOADED)WIDGETS_LOADE...
                               ^
in function "o" called from line 35 col 29 in .boot0
o();const s=require("Storage").readJSON("wid_edit.json",1)||{};const c=...
             ^
in function "loadWidgets" called from line 1 col 157 in iconlaunch.app.js
...screen){Bangle.loadWidgets();Bangle.drawWidgets();}let launchCa...
                                 ^
>

Step-by-step:

1. Factory reset watch via web IDE
2. Install favorite apps, among them Icon Launcher, Anton Clock and Fastload helper.
3. Install widgetupdate.
4. Long press physical button to reset after loading apps.
5. On Anton Clock no widgets are drawn.
6. Press physical button go to launcher.
7. Stuck on "Fastloading..."

---

Posted at 2022-10-28 by rigrig

That's not because of wid_edit, it's the messages widget: it already had an update method which expects an incoming message as argument.

Actually, I think I'd like to rewrite the messages library/app/widget some more, so it just passes everything through Bangle.emit("message", type, message);, instead of directly calling widget methods or global functions.

---

Posted at 2022-10-28 by @thyttan

Ok! EDIT: But I don't seem to get the error if I don't install widgetupdate.

EDIT2: Another thing I'm noticing now is "Exit to launcher"-widget and "Light switch widget" will sit in the same postition, overlapping each other depending on which of them had the latest draw.

---

Posted at 2022-10-28 by @halemmerich

I get about 3-5 calls to drawWidgets with around 100ms each. So the bangle is computing, drawing and using power for 400ms on average while not doing anything useful on each clock<->launcher transition.

Since the main use of the update method is prevention of additional calls to drawWidgets, how about something like the following during drawWidgets:

    let origDraw = Bangle.drawWidgets;
    let drawCount = 0;
    Bangle.drawWidgets = ()=>{drawCount++;};
    for (wd of WIDGETS) wd.draw(wd);
    Bangle.drawWidgets = origDraw;
    if (drawCount > 0) setTimeout(Bangle.drawWidgets,0);

That would reduce drawing the widgets to one additional time after every change for width/area has been done. Still one call more than needed when using update methods, but less overhead on memory and code size. appRect could be updated there as well to keep it dynamic.

The wrapping of draw to check if widgets are currently hidden could be replaced by just setting draw = ()=>{} and restoring that on showing the widgets. Actually the widget_utils module could now be used there. That would probably remove the need for my some of my Bangle.*Widgets-methods altogether.

---

Posted at 2022-10-28 by @halemmerich

I reverted all changes to message, should have kept that one commit... Its now back ;)

I have also seen some problems with overlapping widgets, there are some bugs in the update methods of widgets, will fix that. Or remove the update methods completely, should also fix this :)

---

Posted at 2022-10-28 by @thyttan

Sorry, I mixed up wid_edit and widgetupdate... So I should have said widgetupdate and not wid_edit... I will update #52

EDIT: Updated and now Fastload helper+widgetupdate+messages from your app loader plays nice for me, @halemmerich. wid_edit seemed to work as well.

---

Posted at 2022-10-28 by @gfwilliams

Just a note that because I got a complaint about widclose/etc (espruino/BangleApps@f6b38b3#r88164680) I put some fixes in now that just use drawWidgets for now, just to get it working properly again.

If you're getting 3-5 calls for drawWidgets, it'd be good to find out where they are all coming from.

Perhaps we should consider making drawWidgets actually only queue up a redraw, so if it gets called >1 time before we next idle there is only ever one full redraw?

---

Posted at 2022-10-28 by @gfwilliams

Just tried with:

Bangle.drawWidgets = (dw => {
  return function() {
    var t=getTime();dw();print(getTime()-t);
  }
})(Bangle.drawWidgets);

And widclk installed, and when swapping between the normal launcher and anton clock I see only two calls to drawWidgets taking 50ms each, so I think right now the most recent changes are probably 'good enough'.

---

Posted at 2022-10-28 by @halemmerich

Perhaps we should consider making drawWidgets actually only queue up a redraw, so if it gets called >1 time before we next idle there is only ever one full redraw?

One call will not be enough when at least one widget changes it's width during draw. But we can do with one or two draws, first draw executed instantly and then capture all other drawWidgets and queue one for next idle. I have tried it and it works fine.

The changes to the 4 widgets are working well, I could remove about half of the code of widgetupdate while keeping it working the same way. It now essentially only handles automatically hiding of the widgets and the queuing of drawWidgets

---

Posted at 2022-11-05 by @thyttan

@halemmerich I just worked out that Bootloader 0.101 on your app loader makes it so that 'Swipe menus' doesn't work. The modifications to E.showMessage in this guide also doesn't work with Bootloader 0.101. So something about loading modifications to system functions at boot doesn't work. Just a heads up :)

---

Posted at 2022-11-05 by @halemmerich

I suspect both the example as well as swipe menu work as expected and override whatever exists before :) So probably my wrapping the methods to apply the remove methods are just overriden. Since those would probably most useful in firmware instead of boot code that would not be catastrophic once mine or similar changes are in firmware. There is however the problem that stuff overriding functions like this breaks all new features implemented later in those system functions. Wrapping/Enhancing should probably be preferred to hard replacing existing functions.

---

Posted at 2022-11-06 by @thyttan

How should var/let be used now in regards to fast loading? I saw that you changed most var statements to let statements in launch, @gfwilliams. But there are still some var statements left, e.g. line 58: var app = apps\[i\];.

In iconlaunch code, @halemmerich have changed all var statements to let statements.

I've read some about var vs let here.

---

Posted at 2022-11-06 by @halemmerich

If you want to use a block scope ({ code here ... }) to let the garbage collector do it's job, you need to use let/const and not function/var, because function/var would be defined in the global scope. Everything defined in a block scope with var/function would need to be cleaned up manually before switching.

---

Posted at 2022-11-06 by @thyttan

Ok, thanks! So then I guess I've overdone it with deletes in this PR for dtlaunch? Since most of the variables are now declared with let statements within the block scope of the app, those do not have to be deleted and will be handled by the garbage collector?

---

Posted at 2022-11-07 by @gfwilliams

@gfwilliams. But there are still some var statements left, e.g. line 58

The ones inside a function are fine since they are defined at function scope anyway. It's just the ones in global scope that need to change...

---

Posted at 2022-11-07 by @thyttan

Thanks!

---

Posted at 2022-11-12 by @halemmerich

With the newest additions to the cutting edge firmware I could reduce down the code in my experimental fastload and widgetupdate apps. fastload does close to nothing now, it essentially only shows the "Fastloading..." screen as a visual aid to differentiate between fast and normal loading. widgetupdate still does some trickery while loading widgets to wrap their display input related handlers to prevent them registering interactions while not visible and to reduce the number of drawWidgets calls to at most two per call from an app.

I think the state in the normal development apploader is now plenty fast for daily use and we are currently at a point of diminishing returns for experiments like mine. That does not mean I will stop playing around with this but I think there have been some really great improvements the last few weeks.

---

Posted at 2022-11-12 by @thyttan

The ones inside a function are fine since they are defined at function scope anyway. It's just the ones in global scope that need to change...

Is this true for variables declared without any initiating keyword before them as well? Is x = 42; the same as var x = 42; in that regard?

---

Posted at 2022-11-12 by @thyttan

I think the state in the normal development apploader is now plenty fast ...

Agreed! Thank you for the work on this and other speed improvements, @gfwilliams and @halemmerich!

---

Posted at 2022-11-14 by @gfwilliams

Is this true for variables declared without any initiating keyword before them as well? Is x = 42; the same as var x = 42; in that regard?

No... if you don't have var in a function it's defined as a global variable :)

---

Posted at 2022-11-14 by @thyttan

Thanks!

---

Posted at 2022-11-27 by @halemmerich

I have done a new version of my fastload app. This can fastload any app when it contains widgets and the calling app implements a remove method. It is essentially the same thing .bootcde does, but for any app. The widgetupdate app from my apploader should be removed, if you have it installed. It is not yet modified to work correctly with the slide out widgets and has fallen behind the changes to fastload.

It works by overloading Bangle.load and load to catch all load attempts and then tries using Bangle.load for everything with Bangle.loadWidgets() in it. That causes a fast load if possible or a normal load if the calling app does not have a removal method. Currently this means fastloading everything with widgets from launchers with removal method and normal loading on the way back. @gfwilliams do you think something like this would be ok for the normal apploader?

---

Posted at 2022-11-28 by @gfwilliams

and then tries using Bangle.load for everything with Bangle.loadWidgets() in it

What kind of speed improvements do you see? With the clocks, I found that the act of scanning for Bangle.loadWidgets added enough of an overhead that it wasn't worth it unless it could be precomputed.

Right now I'd like to hold off on changing anything like this by default as I'm not sure so many people have even updated to 2v16 yet (and it's not like that many clocks support the remove method at the moment), but if it's just one app, and it's clear in the description that it is experimental then I think that'd be fine.

[espruino-discuss2]

Posted at 2022-11-28 by @halemmerich

The improvements are pretty much the same as between clock and launcher minus the CRC32 check for changes.
Checking for loadWidgets everytime would take between around 200ms and 1000ms, so essentially eating all improvements. Caching the results and just checking the CRC takes 30ms-150ms.
Assuming a 300ms boot there is a 2x to 5x decrease in loading time from launcher. My bloated bangle install takes a lot longer than 300ms to boot ;)

I would not install this by default or integrate in firmware at this point in time either. Since it has no dependencies and "only" applies what is already done in .bootcde to other loads it should not have that many side effects (there are probably some with other apps redefining load). After leaving an app there is still a full reload every time as long as apps do not widely implement remove.