Below are example of both implementations.
1. Capture image, add text to it, and send it to display device continuously
It was the only way to add modification to preview until picamera ver. 1.8 came out. Because this implementation shows preview by continuously updating image, frame rate can be lower as the image modification process gets slower; Slower the loop process, fewer the image capture, poorer the preview quority.2. Show preview on the bottom layer and add overlay to show text
This way, preview can be shown with show_preview() just like plain procedure without any modification. Text or additional image can be added as an overlay on top, and this layer may be replaced with your desired frequency. As you probably figured out, the additional layer doesn't affect preview quality. The problem is that this preview output directly goes to default display device, /dev/fb0, while PiTFT is assigned to /dev/fb1. Therefore we need to copy /dev/fb0 output to /dev/fb1 with rpi-fbcp. Fbcp takes a snapshot of /dev/fb0, copies it to /dev/fb1 and waits 25ms before repeating. Snapshotting takes ~10ms and with a 25ms delay it gives roughly 1000/(10+25) = 28fps.Comparison
Despite the latency rpi-fbcp gives, the solution with overlay works better for me. I also like this in a point that we can separate preview and overlay implementation.
Now I'll take a break and wait till PiTFT HAT comes out.
Now I'll take a break and wait till PiTFT HAT comes out.
@oklahomers in testing now, coming soon - but no ETA yet!
— adafruit industries (@adafruit) September 19, 2014
EDIT 2015-01-25: Now PiTFT HAT is out in the market.