With v7 I used tv.set_anim_time(ms) to change tab change animation duration but now with v8 I dont know how to get similar behavior.
Can anyone give me the micropython code to change such propierty?
Thanks
1 Like
It appears that the animation time for scrolling is now hardcoded in v8 based on the display size, so I’m not sure that you will be able to adjust it.
(cc @kisvegabor)
I liked it more when I can set on runtime… anycase I will change to my preferred value and recompile.
Thanks
It wouldn’t be a big change to store the related constants in the display driver to allow run time modification.
It still keeps the “scrolling experience” consistent on the display.
For now I have enought setting this define to 0.
I needed this cause I have an slow SPI QVGA lcd and I dont want slow transitions(so better remove them for now)
why its hardcoded? i need to turn off animation time sometimes (as for jgpeiro if there is problems with performance (for example almost full lcd refresh (as example → lv_chart with high freq data change) →
i cant understand why in v8 there are some illogical mandatory changes.
for example → this case OR “lv_timers instead of lv_tasks” - i consider that “timers” is wrong naming that is hard to keep in mind.
for example i have stm32 - there is several timers in project. i need tasks - tasks that will be performed in lv_task_handler. or i can use thread_t in linux to get threads!
but not timers! i have timers already. i like lvgl much, but some things looks very strange for me.
This is just my opinion, but “timer” is actually the more correct term. Calling them “tasks” led to the idea that they were full, OS-level tasks which you could run blocking operations in, when they are really just periodic timer-based callbacks invoked every X milliseconds. This was also the rationale behind renaming it to begin with.
As far as I know most projects don’t need the priority system, and v8 timers work identically to v7, minus the priorities.
However, if priorities are something you really need in your project, I would say you are more likely to benefit from a full RTOS like FreeRTOS.
1 Like
i think freertos is much complicated to use (long task creations(a lot of text)) and so on. and i think lv_task is enough for a lot of projects, also i think even hardware interrupts can work properly with this system.
tasks can be async but its not implemented in lvgl, and thats enough to know.
The main thing of lv_task is easyness - a couple of strings - and we got task.
and timers…i mentioned that it is hard to even recognize.
in one hand we have tasks - that are in straight list (to do list) and in second hand we have timers that are already exists in mcu or SBC. Also timer works like a precision thing, and task and (timers for now) works in lvgl with lv_inc_tick mechanism. I think a lot of people are placing inc_tick in while loop, so timing depends on inc_tick and seems can be delayed if something hard happends in working process (hard i mean - a lot of load(big lcd refresh, math,filter and so on));
Anyway doesnt matter, not my lib, not my rules.
what about anim time? ive found that it would be hard to implement different time for each object(new field in object structure that can store this value) and a lot of prototype and method edition. but sometimes people need this functionality!
Regarding the anim time: tabview now uses LVGL’s built-in scrolling mechanisms. And this scrolling mechanism has some constants to provide a consistent scrolling experience across the widgets. I can imagine 2 reasonable improvement directions here:
- Allow overwriting the global constants
- Add a
flaglikeLV_OBJ_FLAG_REDUCED_MOTION. It’s the analogy of CSS prefers-reduced-motion but on object level.
What do you think?
Regarding task vs timer: even lv_tasks were much closer to a timer than to task:
- called periodically
- can’t give up running to wait for something (e.g. a semaphore, event, or simply delay)
- didn’t have a dedicated stack
As @embeddedt pointed out only priorities were removed. When we talked about it the priority system didn’t seem robust and good enough to be worth having it with all the possible issues.
I think it’s better to allow overwriting the global constants, as this gives more flexibility.
But what if someone still wants to keep smaller scrolling anims? E.g. on a long dropdown which is fast.
Or maybe it’s be the easiest to create lv_tabview_set_tab(tabview, idx, LV_ANIM_ON/OFF) but keep lv_tabview_set_act(tabview, idx) too.
Good point.
Alternative idea: how about allowing customization from LV_EVENT_SCROLL_BEGIN? You could pass &a as the event parameter. Since the event is already being fired anyways there should be no performance penalty.
What could be the customization opportunity?
The event should be sent before starting the animation and &a can be changed like a.time = 0?
Yes; exactly.