Hi @ASMD ,
Based on my own experiences…
I am not familiar with your hardware specifically, so I can only really give generic advice, although you do appear to be using FreeRTOS which I do have experience of.
Having a quick scan over your code I can see you are calling functions from LVGL event handlers and timers which can potentially block LVGL. As a rule personally I have found anything that blocks the execution of LVGL is bad, so any piece of code which makes a call to vTaskDelay() or triggers any kind of tight loop waiting for some other event should be avoided as it is going to delay the screen refreshing in LVGL and you will potentially end up with the type of glitches you are experiencing, I hope that makes sense.
The way I deal with this is to create a system manager process/queue utilising FreeRTOS and run this at a lower priority than the LVGL thread to process functions triggered by the GUI. I also have a single lv_timer_t setup in LVGL which monitors another RTOS queue which allows screen refreshes to be triggered or other events can be posted to LVGL when various external tasks complete. Please see this post for more details.
If you find this approach helpful and have further questions please post here, I will be happy to help if I can.
Note: there could also be something in the Wi-Fi driver itself which is disabling interrupts for a long period, or the network interface driver is at a high priority and doing something to steal time also. These are also possible causes. With that said the above approach is still in my opinion worth using as it helps to keep LVGL working as smoothly as possible…
Kind Regards,
Pete