This serious slowness (considering the small change on the screen) can be caused by many factors. For example, SPI is a serial protocol that already makes pixel-updates much slower, and maximum theoretical framerate can be calculated by multiplying by the SPI clock-frequency and dividing by the resolution and bit-depth. If you update all pixels continuously in the driver that can be a framerate-limiting factor. There should be optimized ways to only send changing content through the SPI and/or using DMA or other hardware-acceleration techniques that the MCU/display might offer. LVGL itself only tries to update what is changing on the screen and there are settings to fine-tune the amount of buffer memory for rendering, setting that buffer bigger might help getting bigger speed. Rotating and blending an image itself is probably taking a considerable amount of CPU-cycles too (without floating point support) and might be calculated for the invisible/transparent parts of the image too. Hopefully your needle is an image of as small dimensions as possible. But these are just some tips about possible causes, the optimization and finding the real cause can only be done efficiently on the actual devboard IMO, too much variables…