vindar
Do rotation with MADCTL register
This should improve performance as we dont have to deal with rotating in software anymore.
Im currently prototyping on my custom fork (which has a lot of stuff removed, so i sadly cant create a pull request atm), but currently im dealing with diffing issues where a lot of the screen isnt getting drawn, sadly
Hi,
the first version of the library did use the MADCTL register for hardware rotation but doing so creates screen tearing when the orientation is not 0 because the screen pixels on the screen are always refreshed in portrait orientation 0 (irrespectivly of the MADCTL register value). In order to prevent screen tearing, the pixels must be uploaded just after the scanline hence must be uploaded in the orientation 0 ordering... This is why the driver performs the rotation in software prior to uploading.
Moreover, using hardware rotation does not really reduce the compute cost. In my experiment, adding the software rotation add only around 200us while computing the diff buffer already uses more than 1ms....
For this reason, I do not think the slight improvement that MADCTL would give is worth losing screen tearing prevention mecanism.
Thats a good tradeoff then. I did not think about that. Thank you for the quick write up!
Did you experiment doing the rotation with the PXP? I tried once quick and dirty but results were shockingly slow .
Hi,
That is a good question about the PXP :-)
I never used the PXP myself so I do not know much about it but from what I understand (and read on the Teensy forum...), PXP operations for copy/rotation are not faster than regular code: the advantage of the PXP is that it frees up the MCU during operation so the program can do other things meanwhile...
Unfortunately, the way the ILI9341_T4 driver works, the copy/rotation from the user framebuffer to the internal framebuffer must happen after the diff has been computed and before pixel upload starts. This means that nothing else is happening at the same time.
Yet, using the PXP instead of regular copy may be useful when combining the driver with an RTOS or with teensythread...
Another possibility would be to perform the diff computation and set up the pxp in the update() method but then return to the user immediately (before the end the PXP copy) while setting an interrupt to start the transfer after PXP is done ? Might be worth investigating...