Rockbox

During playing around with the YUV-blit function for the iPod Video I came around the following idea and tested it: One major delay of the Video’s LCD-driver is the sequence where we wait for the LCD to be ready for the next screen update. This always needs 14ms, so the drivers yields in such situation.

1st try: Do not wait, but always update the LCD.
This shows a significant speed-up for all videos from a resolution of 224×176 and lower. A maximum of 75fps (before: 47) is reached at 128×96. Nevertheless we very rarely get some errorous pixels while playback. Conclusion: The yielding does not improve the decoding performance.

2nd try: Do not wait, but drop the whole frame update when LCD is not ready.
This will kind of destroy the YUV-blit-measurement in test_fps, but has even more positive effect on the video playback. In this case the yuv-conversion as well as the transfer to LCD’s data port is dropped, the next possible update will take place. While video playback the yuv-blit function is called in a cyclic manner. So, you will therefor not loose any frame as there has been no LCD update at all while the former implemented yielding. Effect is that you get a really significant increase in video playback from 224×176 (now: 28fps, before: 24fps) which goes up to 107fps for 128×96.

This change can only be done as yuv-blit is called repeatedly and cannot be applied to lcd_update_rect(). There is no interference with lcd_update_rect().