When using multiple update functions through lv_timer_create, when lv_timer_handler runs it executes all timer callbacks if needed (depending on respective delays).
But internal handling of touches, screen updates or any other lvgl-managed work happens only when these updates are done. So when you need a long time to run them (let’s say 100ms), touch responsiveness feels awful.
What would be the right way to tackle this problem, having lvgl touch data (lv_indev_data_t) taken care of, and improve responsiveness of the screen, while breaking individual updates functions into smaller chunks ? May be related to timer lv_indev_read_timer_cb.
I think the root of your problem is the timer callback possibly taking 100ms. What on earth are you doing in this callback? I suggest splitting whatever you are trying to do into smaller chunks and using that timer to set a flag to start executing that function.
This situation occurs on a specific screen, which contains a lot of logic to update widgets. No other timer on this task other than the display update task.
Of course, part of the problem comes from the 100ms cost of the update, of course it should be split or optimised / reduced. Splitting it into smaller chunk would not change a lot, as all timers are executed sequentially, thus execution times add up.
Setting a flag in the timer to execute the function, would not change a lot: the work would have to be executed in another function, which can’t update LVGL outside of LVGL update cycle (thread safety etc).
You need to split up that functionality and somehow manage it outside of a timer callback, or update less on your display at once by only updating x amount of widgets at a time. You really should view the timer callback as you would on a microcontroller. Should take up very little time each time they are called, not a 100ms.
The 100ms timer duration is not part of the problem, it is the problem.