There are several factors limiting the real-time performance. Certainly, chart is a rather capable, but therefore a bit overcomplicated widget. Study the code in lv_chart.c, and you will see that there are many possibilities to optimize it if you only want to display an audio waveform. I’d suggest to copy the source, and remove all unnecessary code.
The second problem is the update speed, which means the time to transfer the pixels from memory to the display controller. What is the resolution of your display? Obviously it takes (much) longer to update a high-resolution screen. Do you use a parallel (i8080), or a serial (SPI) interface, or eventually RGB? Depending on the resolution SPI may not be fast enough for real-time update. Parallel may be OK, especially with 16 bits. In any case, you should use DMA for transferring the data. The best is to use the integrated LCD controller of the Teensy with either a 16-bit parallel, or an RGB interface.
The third problem is tearing. If the screen update is not synchronized with the hardware refresh (e.g., using the TE output of the controller, or reading the scanline), then the screen will not be updated completely in one refresh period, which results in visible tearing. This is especially bad if your display has a native portrait orientation, while you want to use it in landscape mode. This configuration causes a diagonal tearing, which is even more noticeable. This can be solved only by rotating the screen in memory (simply reconfiguring the controller is not enough), and updating the display in its native direction. However, this needs additional CPU time, thus it makes the update even slower. In general, if you have enough RAM, you should use direct mode with double buffering for the best result for animated display.
The fourth problem – somewhat related to this – is that if you use partial rendering in order to save memory, then you need to be aware that you should only update the screen when the whole screen has been refreshed, otherwise you will almost certainly run into tearing problems. This can be checked in the flush callback using lv_display_flush_is_last()
.
The fifth problem is the overall frame rate. To have smooth scrolling you’d need a rather high (>30 FPS) frame rate. This not only requires a fast processor (possibly using hardware graphics acceleration), but you need to configure LVGL for a low refresh period.
As you see, there’s more to it than just efficiently rendering the waveform to the frame buffer. Depending on your hardware, it may not be possible to get a smooth animation. But even with a capable hardware it need some consideration to configure your system.
The Teensy 4.1 is rather powerful, but I’m not sure how well the i.MXRT1062 is supported by LVGL. In any case, try to use a parallel interface instead of SPI.
Meanwhile check out the TGX demos for some smooth 3D animation on the Teensy. It would be an interesting project to integrate TGX into LVGL. Unfortunately, the LGPL license of TGX makes it difficult.