Years ago I had a project that used graphics via a Microchip PIC32MX and a separate graphics controller/RAM that worked very well, with very speedy operations and no artifacts when updating the screen, via highly optimized assembler routines for the graphics, and no libraries whatsoever. The customer hired their own firmware engineer who totally updated the project using QT, being he was familiar with QT on Windows and other CPUs. He ended up making the system almost unusable due to very slow update speeds and lots of artifacts when updating the screen. All their customers complained about the "downgrade". They asked me to take back the project, but I refused, so I don't really know the details of how QT was implemented on the MCU. But let's just say the performance on MCUs, at least the one I saw, was not in any way acceptable. So before you decide on QT, you might want to check if there's any example videos of it running on the MCU you're interested in, to see if it meets your performance goals. Pay close attention to the LCD resolution, and how screens are updated, and how much is updated at one time. With only updating minor details, often poor graphics performance can be masked, but when changing to an entirely new screen there's no way to mask the lack of performance.