Display corruptions since upgrading to v2.15

Ever since upgrading Bangle.js 2 to v2.15 I have a corrupted watch face about every other day.
Mostly the corruptions are on the top or bottom of the screen.

https://photos.app.goo.gl/rJGqY8sYtKTkqH­kZA

Loading the settings and returning back to the watchface resolves the issue temporarily.

The watchface I am using is AnDark. I didn't have this issue with earlier versions.

Are you on 2v15 or on a cutting edge build? This seems to be the widgets being drawn and the inner watchface then drawing over them. So watchface probably draws the outer dial, then widgets are drawn and the inner dial is then refreshed, probably every minute or so. That could be a side effect of the fast loading of the clock after the launcher, but that would only occur on the cutting edge build.

This seems to be the widgets being drawn

AnDark doesn't call loadWidgets at all, so the problem seems to be that widgets are/were loaded+drawn anyway.

Thus the question about the cutting edge build. In combination with a launcher implementing setUI with remove handler that would currently be expected.

Just to confirm @user141359 - this only happens when you go to the launcher and then back again from the launcher, without running an app from it?

In combination with a launcher implementing setUI with remove handler that would currently be expected.

Argh, that's frustrating. I don't know why I didn't fully appreciate that when I changed the default launcher.

@halemmerich I guess we've got your changes to loadWidgets (with hiding) that could be used? Or I guess we could have the launchers only do a fast load if the clock app contains the text Bangle.loadWidgets?

I'm also wondering whether maybe I should just implement the hideable widgets library (using overlays) and then include that in any clocks that don't explicitly load widgets? It wouldn't work for clocks that aren't in the app loader though

@halemmerich I guess actually my change to the launcher would apply to all builds - it's just anyone that has launcher 0.15 or later

I guess actually my change to the launcher would apply to all builds - it's just anyone that has launcher 0.15 or later

Yes, that is probably correct since it evals directly.

I guess we've got your changes to loadWidgets (with hiding) that could be used?

The current state of my widgetupdate branch probably solves this independent of the build. It does however do some things that probably need some thought before implementing directly in firmware:

• Keeping state of widget visibility in a global way, currently that are variables in block scope of the boot.js code
  
• Currently it overrides the load method to reset the state, but we could probably do a appload event or something to handle that outside of load.
  
• Hiding currently only catches the display handlers(touch,swipe,drag) if they are set directly during load by the widget. Handlers set during the livetime of the widget are not caught. Some widgets do replace their handlers regularly. Maybe some documentation on restrictions for widgets would suffice.
  
• The first dummy draw using FAKE_G is not necessary, just a try to save a little bit of drawing time. It could be replaced by a standard call to drawWidgets.
  
  

Checking for loadWidgets in the code seems expensive, but maybe we could mark apps in their info files as using widgets.

Another idea would be defining a new style of widgets, where they are not arbitrary code somehow modifying WIDGETS but an object like

{
load: function,
remove: function,
draw: function,
update: function, //Must handle hiding and reaction to Bangle.CLOCK, e.g. removing handlers
area: function, //Allowed to be modified by load/update/remove but not draw
width: function //Allowed to be modified by load/update/remove but not draw
}

and then only fastload if no classic style widgets are loaded. That would feel less workaroundy.

Ok, just fixed this if you update all apps from the app loader.

@halemmerich it's an interesting idea about the widgets, but I think right now, changing the way widgets are defined and loaded is a bit too much of a wide-sweeping change - I'm pretty sure we'd create more bugs than we fixed :)

I was just about to add a default-off option for fast-loading in the launcher, and I realised that now .bootcde caches the clock's filename, the loading of the clock info is only done once when the clock changes. So instead what I've done is added clockHasWidgets to the settings, and this is updated either by the boot code or the settings menu when the clock changes.

So, this should fix it with no impact in speed (apart from maybe <0.5s when changing the clock)

Nice low impact solution for this. There are edge cases like some clock storing the Bangle object in another variable and calling loadWidgets on that, but that probably never happens.

I think a new style of widgets could be implemented without breaking backwards compatibility to the old widgets style. Only generic fastloading would not work with classic widgets present. The other way around (old firmware and new widgets) would be problematic since the widgets could not be correctly loaded then. I will probably toy around with the idea to see if it leads anywhere.

2v15 or on a cutting edge build

I am on the release build, not the cutting edge build.

On the 7th of October I updated the watch to the release 2v15 build, and I also updated all installed apps to their latest release version. Before that I didn't have a problem (I think before that I was on 2.13, build but I can't remember for sure).

There is a chance that the corruption is not actually caused by the 2V15 build but by an AnDark update. I suspect it's the watch OS but I can't fully rule out other factors since I updated them at the same time.

Just to confirm @user141359 - this only happens when you go to the launcher and then back again from the launcher, without running an app from it?

I actually don't know how it happens, I just look at the watchface randomly to read the time and about every second day I notice it is corrupted. At first I thought it was probably because I had enabled debug output during the update process because I had a bit of a problem connecting to the watch via Blueooth at first and I thought the debug output would give me an indication why I couldn't connect to the watch. Later I realize I could connect without problems if I disabled Gadgetbridge first. Then I forgot to turn off Debug output again. But a week ago I disabled debug output and rebooted and the display corruptions keept happening even with debug output set to Hide. That's when I realized I should probably make a bug report.

Every time I enter settings and go back to the watch screen I believe that causes the watchface to redraw, and so I think that fixed it every time so far.

I am sorry I can not give more details. I haven't tested with another watchface so far.

I attached more photos. Those photos were made before I had switched off debug output, the photo in the original post was made after I had switched off debug output.

Appreciate the extensive response to find the underlying fault!

1 Attachment

Ah yes, one more thing I forgot to mention: Rarely I have been seeing random white bars instead of Date and Charge. But I have been having this problem both before and after the updates on October 7th (both with Settings - Utilities - Debug Info set to default Hide). So I think this is an unrelated issue.

And on August 2nd I had a a third, probably unrelated issue where the watch had completely crashed and kept displaying an old time from 2 hours ago without updating the watchface any more. The settings app would not load, and also the backlight would not turn on or the seconds hand show up on accelerometer movement.
Only a very long press completely rebooting the watch fixed this.
This was scarry to me because I am afraid of reading the wrong time and being late.
Luckily this was the only time this happend since I had been using it since January.

Example of white box instead of text issue:

1 Attachment

The first 4 of your pictures are most probably caused by the fast loading and widget handling and should be fixed by updating to the current versions on the development apploader https://espruino.github.io/BangleApps.
The fifth picture is caused by having debug output enabled, that moves the screen up and the clock draws parts of its graphics over that moved image.
The white box issue is probably somehow caused by a bug in the watchface app and as you assumed unrelated to the problem and fixes regarding the widgets.

I believe the issue with the boxes is because AnDark doesn't reset graphics state (background color) between draws - it's not expecting any widgets to be loaded so it doesn't expect any changes. Again, the recent changes should fix that if you update now (and make sure debug is disabled and you won't see the screen shifted up).

As for the hang - that is a worry. Were you connected by Bluetooth to a phone/computer at the time? That seems to be about the only time we've noticed an issue (usually when Gadgetbridge is connected) but it seems quite rare.