Making Bangle.js more responsive - please test! #7035
Replies: 1 comment
-
Posted at 2024-07-04 by woogal A couple of things I've noticed -
Posted at 2024-07-04 by @thyttan Thanks @woogal! Regarding 1:
Regarding 2: Posted at 2024-07-04 by @thyttan I've pushed a version 0.02 with a fix to the development app loader: https://espruino.github.io/BangleApps/?id=setuichange I also realized there's a bug where if you do e.g.
We will add two drag handlers, the mode "updown" one and the custom one. But we will only keep the custom handler in @gfwilliams what do you reccon:
This doesn't happen for the touch handlers since we only add the last of them at the end of setUI's code. I wonder if we should change this so they add to each other rather than overwrite, like for drag, in order to preserve the callback functionality mode "updown" provides even when a custom handler is added. Posted at 2024-07-04 by woogal @thyttan thanks that version has fixed the btnWatches error :) I think the first problem happens with any clock, and I'm using the default launcher. At first I thought it might just be something I'd done in my own clock so I switched to Anton and it happens there too. Long press to reboot and immediately after, with the watch still unlocked, the first press seems to be ignored, after that it functions normally. If I reboot and wait for the watch to lock then the first press unlocks, the second press gets ignored, and I have to press for a third time to get to the launcher. Posted at 2024-07-04 by @thyttan Hm. What firmware do you have currently? Could you:
... and see if that helps? I'll install anton clock and the default launcher to try to reproduce as well. Edit: I can't reproduce on my current setup. Edit: could you also also copy/paste the "Apps installed" field from the "More ..." tab of the app loader? Posted at 2024-07-04 by woogal Firmware is 23 (stable, not cutting edge), reinstalling didn't make any difference. Apps installed are - Posted at 2024-07-04 by @thyttan I just did:
... and can't reproduce your problem. So I would guess you can fix it by factory resetting and then set up the watch again. If you don't feel uncomfortable (privacy/sensitive data reasons) sharing that backup you did you could send it in a message to me here on the forum and I'll restore it to my watch to see what happens. Posted at 2024-07-05 by @gfwilliams Thanks for the quick fix @thyttan - I'm just pulling that into the main app loader now. Wrt
OR (and maybe this makes more sense) we just throw an exception if Posted at 2024-07-05 by @thyttan
I think this is the way. There's a part of me that thinks it's cool to be able to add on the custom handler on top of the standard Posted at 2024-07-06 by @thyttan
Ok, I now managed to reproduce by doing (edit: see my next reply for additional info re reproducing):
If I change this:
... to edge falling like this:
... the problem goes away. So somewhere there is something hindering the watch from acting on the first rising edge after a long press of the hardware button. But not the first falling edge it seems. Posted at 2024-07-06 by @thyttan By changing to a clock that takes slightly longer to load, e.g.
The problem only manifests for case 2 (on a factory reset watch as well as on my personal usual setup). Posted at 2024-07-06 by @allObjects I'm not so sure if that is the only (or good) way to give the impression to be (more) responsive. Why? If something 'goes off' on the press event, you cannot 'go back'. To still support long presses requires two different contexts and the awareness of them - action starts either on press or on release. To be aware of which context is active requires a visual cue. My solution to give feedback - visual cue - to the user that the press has happen / is noticed - and I think it is all about that - can be conveyed differently, for example with a quick change / flash of a half circle or oval next to button. The case of press event starts something is still a valid case, thinking about the cursor keys on a key board or the special character - character w/ diacritics - in pop-up. The response to such a press would be passing callback that is then called over and over on a configurable interval until release. Double press in rapid fashion is could be integrated as well in the event. In the beginning when I had to use a single button interface vs a two - left and right - button interface, it created some relearning pain, but the value of dealing with just a track pad - position irrelevant - made up for a lot of it. When building the UI - https://www.espruino.com/ui - visuals at https://forum.espruino.com/conversations/292990/ - I had to handle the touch this way... on touch a visual cue is give to the user about it: an element fence or border shows as a white rectangle, which goes away on un-touch (for speed sake redrawn in same place in background color... all on a 'big', 262K color serially connected - thus slow - display. On other occasions I was trying to save and restore, but that took ages, see https://forum.espruino.com/comments/11906513/. With Bangle2's limited color depth and speed, it should not be that a big issue to save the few pixels around the button and flip the around and then restore, or some other kind 'flash', noticeable by the user. This kind of a visual cue could be a 'OS' level integrated option. It would also have to handle app-redraws of the area, so than on release the correct display is restored in this area. Side note: touch screen vs. (single) button is not that much difference: touch is just setting the focus before treating the touch (or release), and w/ button, the select happens in a different way. Without touch there are two modes: navigation and (data) entry/edit mode. In navigation mode, a short press unselects current element and selects next element, a longer press switches into the entry and would also be either directly the return to navigation mode or to a (popup-) menu, that even allows a cancel / restore (and other - app - options). A single button UI needs absolute consistency in behavior for a 'happy' - not confused and giving up - user. Posted at 2024-07-08 by @thyttan @allObjects Did you try the test app linked in the opening post? Would be interesting to know if your viewpoint is also based on testing that or if it's a more general viewpoint not based on testing it. Thanks 🙂 Posted at 2024-07-08 by @gfwilliams Honestly, I wasn't very convinced by @thyttan's idea either - but then I tried it and it did make a huge difference to how the watch felt. Regardless of whether there is feedback, making the new app load ~200ms or more quicker is a big improvement. The problem is that while several people were very vocal about wanting support for long button presses, the reality is that nobody actually uses them, as the long press currently reloads to the clock at an OS level. ... but even if someone did want to use long presses you still can do it easily (with the
Hmm, this is a problem. So I think what's happened is:
The solution that comes to mind is:
Posted at 2024-07-08 by @allObjects @thyttan and @gfwilliams, I see the value of firing on press when there is no other option and I understand also the issue of double press because of timing and queuing of the events. For that reason - and especially on app / context switch - repeat has to be disabled and the new context (app) has to arm the button again the way the app expects. Posted at 2024-07-08 by @thyttan
I don't think this is it, at least not the full picture. It feels like it doesn't add up with the following I posted above:
To clarify that, I do for case 1:
And for case 2:
I think points 6 and 7 in case 2 rules out that it's a problem with the I believe the problem manifests when we hold the button and go through an regular, non-fastload, load cycle with the whole boot process being run and only release the button after the boot process has finished. If we release it ASAP when the boot process was initiated there seems to be no problem. Can it have something to do with the watchdog functionality? Posted at 2024-07-09 by @thyttan The problem is reproducible also with this code:
... when set as the current clock (I set I look at the prints in the Web IDE console field to see the problem when running this code. So that should narrow it down some more. Something about If I release the button ASAP when the Posted at 2024-07-10 by @gfwilliams Thanks! Yes, I see what you mean. Just fixed it in latest cutting edge builds - it was the debounce logic getting out of sync with the button state because we were 'eating' the first button release event after a restart to avoid starting the launcher immediately (because right now we look at the falling edge) Posted at 2024-07-10 by @thyttan Awesome, thanks! Just tried it and that fixes it on my watch. 🙂 As expected then maybe though, if I remove Posted at 2024-07-10 by @gfwilliams Damn, thanks! I fixed it when you fixed now. Posted at 2024-07-10 by @thyttan Thanks - now works as expected both with and without Posted at 2024-07-10 by @devsnd Just wanted to report in: I've tried setuichange for the past week and everything worked nicely for me, the watch feels much snappier. I think this change is awesome and the impact is huge! @gfwilliams I'll try to find the build you once made that would install apps on the internal storage instead of the one connected through SPI. I wonder if that shaves of another few milliseconds from the startup time of the apps. Posted at 2024-07-10 by @thyttan
I think it's this your after: https://forum.espruino.com/conversations/374260/?offset=200#17407732 Beware of this though: espruino/Espruino#2509 Posted at 2024-07-11 by @gfwilliams
I did one recently for someone else - try this! This one uses only internal flash, not external too (as there were issues there as @thyttan has pointed out). Attachments: Posted at 2024-07-11 by @thyttan Despite its name it seems that might be a Bangle.js 1 build. The app loader switches to Bangle.js 1 mode and i get a "Hold BTN3 to reload" (or similar) message after installing apps. Also see attached screenshot. Attachments: Posted at 2024-07-11 by quietCoder500 I am having no problems with it over the past week and I have 42 apps installed. widlock (0.08), kbtouch (0.04), icons (0.02), clock_info (0.12), clockbg (0.03), alarm (0.48), sched (0.26), health (0.30), notify (0.14), boot (0.63), waveclk (0.03), messageicons (0.07), messagegui (0.79), widmessages (0.06), widslimbat (0.01), widdevst (0.05), messages (0.62), ios (0.18), recorder (0.43), gipy (0.25), bikespeedo (0.07), openstmap (0.30), wclock (0.04), magnav (0.07), weather (0.26), locale (0.19), calendar (0.18), dvdbounce (0.01), hourstrike (0.09), setting (0.73), widcasiologo (0.01), lcdclockplus (0.02), clkinfogpsspeed (0.01), advcasio (0.06), powermanager (0.11), setuichange (0.02), dtlaunch (0.25), barometer (0.04), smpltmr (0.09), multitimer (0.11), widalarmeta (0.11), clkinfostopw (0.03) These apps all work with setuichange (0.02) Posted at 2024-07-12 by @gfwilliams
Ahh - sorry! It's just that it reports its name to the App Loader as This one is fixed: Attachments: Posted at 2024-08-08 by @thyttan
@devsnd did you end up testing this? What was your experience? Posted at 2024-08-12 by @devsnd @thyttan I've tried it out since yesterday. While the watch feels much quicker in response (I didn't measure anything, but I already love the additional speed gains!), but I seem to have a problem with the boot0 constantly being regenerated, seemingly on every app start. I don't know what triggers it, but that also seems to break a bunch of apps, some apps don't redraw properly after the boot0 regereneation maybe? I tried restoring a backup right after flashing the internal-flash build, which failed in the middle. I though that I would have about 1MB of space of which my backup would use about 600kb, but after flashing the build I notices that there only remains 360kb, so that explains that. After the failed restore, I instead used the "install default apps" button in the app loader to wipe the device and install default apps. Other than the constant boot0 regeneration breaking some apps everything seems to work fine. I would love to use this build with the internal flash + fastloading + setuichange. This makes all the difference in UX. It feels like a brand new watch, like a BangleJS2.5. I even disabled the "fastloading..." popup, as apps appear in under a second. If I clean up some of the apps I barely ever use, I can easily get away with 360kb to store my favourite apps. It would be perfect if only health and GPS logs could be written to the external flash for example. Now I feel bad about the splash-screens that I had built into my apps, which now make the app switching extra slow, which felt ok before, but now feels terrible when all other apps switch so very fast! Anyway, all of this is a great step forward for a great UX for the bangle! I hope that we can find the problem of the boot0 regeneration together... what could I do to get some more debug info about that? Posted at 2024-08-12 by @devsnd FYI, I had to use DFU to get my watch in a working state again, as the normal firmware updater failed on the internal-flash-firmware. There were multiple apps not working, it felt like a part of the memory was corrupted (just a hunch). The watch would start compacting storage on a firmware update, but I guess there wasn't enough space left for the firmware file afterwards. I had this error when launching the health app for example. (see image) So long story short, the firmware isn't there yet for everyday use, but if it would work, I would happily trade the storage space against a snappier watch! Attachments: Posted at 2024-08-15 by @thyttan @devsnd Thanks for testing! That seems to line up pretty much with how it ran on my watch as well. Just for clarity, did you flash the most recent one,
I'm not sure myself - but maybe it makes sense to talk about/document it more on this gh issue: espruino/Espruino#2509 Posted at 2024-08-17 by @devsnd Yeah, I flashed the most recent one that gordon posted! The github issue pretty much describes the problem I had; I could not pinpoint what happened exactly, but in the beginning the noflash firmware ran perfectly fine. I installed a few apps manually and everything was very snappy. But after trying to restore my backup from the external-flash, I ran out of storage, so automatic compaction kicked in, trying to save the day. After that only half of the apps worked and I had constant .boot0 regenerations. However, I then tried to remedy the situation, by reinstalling the default apps, but at that point I could not return to a working state, so I went back to the regular firmware. What's nice about all this, is that when I went back to the regular firmware, my watch was back in its old state, as the external flash was never modified. Therefore I'd be happy to test more, as it doesn't seem to risk using the watch as daily driver afterwards. Posted at 2024-10-15 by @thyttan @gfwilliams is it time to make the Should a similar change be introduced for Bangle.js 1? Posted at 2024-10-16 by @gfwilliams Yes, let's try and get it in. It'd be nice to make it seem a bit more responsive! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2024-07-04 by @gfwilliams
At the moment Bangle.js responds to button presses when you release the button, rather than when you initially press it. It's because initially some users wanted the ability to detect a long press of the button (which you can't know when the button is first pressed), but the time taken to press the button and release it is quite noticeable, and does really make the Bangle seem less responsive than it could be.
Despite detecting long presses seeming like a good idea, very few apps actually do it, so thyttan has been working on seeing what happens if we respond when the button is pressed rather than released: espruino/BangleApps#3435 (apps could still use button release if they need to detect long presses)
You can now test this out by installing the https://banglejs.com/apps/?id=setuichange app - and I'd really like to her your thoughts after trying it...
Does this break anything?
run/runplus
currently start/stop recording when the button is pressed (but you hold the button to exit) - so those need tweakingspotrem
) directly access the button event and then won't see an improvement hereBut personally, I feel like the difference in perceived speed when moving from clock->launcher and back (which is what happens 80% of the time) makes this more than worth any small inconveniences
Beta Was this translation helpful? Give feedback.
All reactions