Unclear about async event loop on mcu

[yanshay]

I'm building an app with splint on ESP32 with async.
For that I need to develop my own async event loop.
I've seen #2793 (comment) that sketches how an async event loop should look like, however several things I'm unsure about:

1. What should I do when slint::platform::duration_until_next_timer_update() (which returns an Option) returns a None? Should I treat it as 0 or as infinite or something else?
2. The mentioned event loop sketch doesn't reference the if window.has_active_animations() which I understand needs to be considered as well. Whats the correct way to deal with this? While there are active animations should I poll the touch and call update_times_and_animations()? Surely I need to call the draw but what's the proper way in an async app to deal with drawing together with polling touch and updating animations? I can't go into a blocking loop for sure (since other async elements in the app won't function).
3. If I have background activity, let's say driven by wifi comm, that needs to update the UI (when there isn't any user interaction or animations), is there a 'proper way' to wake up the app to get updated or do I need to build my own custom mechanism for that? (I'd expect that my calls to update UI will wake up some async waker on slint side that I could wait on in my async loop without me having to calculate whether UI needs an update or now). If not an async waker then some flag I could check on myself?

[ogoffart]

1. What should I do when slint::platform::duration_until_next_timer_update() (which returns an Option) returns a None?

None is the same as an infinite time.
So this should return pending to go to sleep until the next event (eg, touch/keyboard) comes in, or for the next animation.

2. The mentioned event loop sketch doesn't reference the if window.has_active_animations() which I understand needs to be considered as well. Whats the correct way to deal with this?

If there are animations you probably want to spin your loop as fast as the screen can refresh. So not go to sleep and poll right away.

3. If I have background activity...

Since it all happen in the same thread, I think you can just call set_property and so on on the UI at any point

[yanshay]

I did that by using the MinimalSoftwareWindow code. I only had to remove some code related to metrics, it seemed like used for measuring performance or something like that and it involved private members so couldn't be used in my code.

It works, but I think I found some important bug/mistaken-assumption for the case of an async event loop. I found a workaround for the symptom I identified, but there maybe other cases.

What I witnessed is that animations driven from rust code (by updating animated properties) were skipped immediately to the end without any animation, while animations (same one) triggered by touch were performed flawlessly.

It seems to me that when animation starts, slint assumes the internally stored time (from last time it checked) is up to date. This is good enough when the event loop is running prior to the animation start (for any reason) which is the case in non async event loop.
In the case of async code, the event loop could sleep for a long time and then waken up due to another task setting some property that will trigger animation. In such case the time slint knows about is outdated. Then, it seems that when animation is calculated it checks current time against a new time it takes from the system, and if more time than animation length passed from that outdated time it just skips the animation altogether, which is the skipping of animations I witnessed.
I solved this by calling the update_timers_and_animations from the request_redraw mentioned above. It wasn't enough to call it after the event loop woke up, that was too late for some reason, it had to be done earlier and the only spot I had for that was in the request_redraw.
I think the proper behavior should be that as animation starts, slint should take an updated timestamp as animation start time, and calculate from that time on based on additional time stamps taken along the way.

• While I solved it for now for the case I witnessed, I can see how internal changes could break that solution so would appreciate if you could validate my understanding and whether my solution is the best/covers other related timing issues or maybe this requires some change in the animation code?

In general, in async the event loop is not running all the time, maybe there are other implications as well (e.g. if slint had timers exposed in its language, I couldn't find such).

I think also in multithreaded apps such symptoms could arise because there event loop could also go to sleep and waken up by another thread to set properties that will trigger animations and same issues would occure there.

[ogoffart]

Animation start from the time of the last call to update_timers_and_animations

You should call that from one of the future that is always being polled or something to make sure that the time is always updated.

I think also in multithreaded apps such symptoms could arise because there event loop could also go to sleep and waken up by another thread to set properties that will trigger animations and same issues would occure there.

In this case, the event loop thread should always call update_timers_and_animations at the begining of the loop iteration when it gets woken up, before the events that sets properties are run.

[yanshay]

Animation start from the time of the last call to update_timers_and_animations
You should call that from one of the future that is always being polled or something to make sure that the time is always updated.

Doesn't this requirement waste energy? In the case of microcontrollers, potentially battery powered, this prevents the application from saving energy. I'm trying to have the microcontroller asleep as much as possible for that.

Couldn't animation start from the real time they are triggered by checking time as they start rather than relying on previous time check? There's the duration_since_start provided as part of the platform. It's also more accurate.

Do I miss anything with my alternative solution to call update_timers_and_animations only at request_redraw? For my animations so far it seems to work.
Any other functionality in Slint that wouldn't work properly if I don't call update_timers_and_animations continuously?

[ogoffart]

You don't want to wake up for no reason, but you want to make sure that update_timers_and_animations is called every time the event loop is being polled. So don't wake up for this. But when the CPU wakes up, make sure that the future that update the time is being polled.

If doing it only at request_redraw works for you, then that's good. But it may not work if there is no changes in your screen for a while, and then an interrupt cause something to change a property which would trigger an animation.

[yanshay]

You don't want to wake up for no reason, but you want to make sure that update_timers_and_animations is called every time the event loop is being polled. So don't wake up for this. But when the CPU wakes up, make sure that the future that update the time is being polled.

I did that and it wasn't enough. If property was set in an async task, triggering the wake up of the event loop, and there I immediately called update_timers_and_animations as first thing, it was too late and animation didn't work. I had to call update_timers_and_animations before setting the property or at the request_redraw.

If doing it only at request_redraw works for you, then that's good. But it may not work if there is no changes in your screen for a while, and then an interrupt cause something to change a property which would trigger an animation.

Wouldn't any change that drives animation first drive slint to call the request_redraw (the name implies it's required to have the draw take place)? (it's not me calling it, it's slint that calls it).

I was thinking it may fail in case of timers functionality if there is such, that required constant time update for things to work properly.