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

You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.

•

Gordon

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!

•

halemmerich in reply to @Gordon
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.

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

About

Espruino