Input device read period in milliseconds was unstable

Lvgl Version: V8.3.5

File “lv_conf.h”
/Input device read period in milliseconds/
#define LV_INDEV_DEF_READ_PERIOD 20 /[ms]/

The input device read cycle set to 20ms, but the read cycle was more longer when you drag a slider.
Does image rendering block input reading?
I flipped an IO port in the “read_cb” touch point callback function.
It works fine and keep cycle at 20ms work idle, but the cycle at 100ms or more when I drag the slider.

The same test worked fine on TouchGFX. This is an important reason why LVGL’s touch is less fluid than TouchGFX’s.
Is there a way to deal with this? This is very important to me, thank you.

show how you manage lv_inc_tick

I call “lv_tick_inc(1);” in the 1ms interrupt;

Seems your code is top secret , then ask crystal ball.
But realy when you place inc_tick in 1ms systick int, and your lv_timer_handler in clean loop …
And yes exactly slow flushcb render and slow readcb can corrupt timing

void PIT1_IRQHandler(void)
{
static uint32_t s_ulLvglCnt = 0;

if (PIT_GetStatusFlags(PIT1, kPIT_Chnl_3))
{
    PIT_ClearStatusFlags(PIT1, kPIT_Chnl_3, kPIT_TimerFlag);
    
    // Lvgl Time Base
    lv_tick_inc(1);
    if (++s_ulLvglCnt >= 5)
    {
        s_ulLvglCnt = 0;
        
        ulLvglProcTrig = 1;
    }
    else{}
}
else{}

}
static void MainLvglProcess(void)
{ // 5ms Triger
if (ulLvglProcTrig)
{
ulLvglProcTrig = 0;

    lv_task_handler();
}
else{}

}
int main(void)
{
//…

while (1)
{
    MainLvglProcess();
    
    //...
}

}

My real way of using it and without RTOS.

right func is

lv_timer_handler();

and i repeat lvgl speed is baced on flush cb

static inline LV_ATTRIBUTE_TIMER_HANDLER uint32_t lv_task_handler(void)
{
return lv_timer_handler();
}
NXP officials put a layer on it.

Slow image rendering causes read blocking, right?

Yes and not only read , but all blocking without OS. Optimal render is MCU offload DMA etc. But LVGL not handle hw part code, this is your job or ask NXP