Ok no worries. I did a few tests and couldn't get the sensor to just send a single pixel per bayer quad, I don't think my (guessed) understanding TIMING_X/Y_INC is correct.
Anyway, good news I've solved my perf problem. My code rips out the red pixels from a 2592x480 rawcam bayer buffer into 1296x240 array, does a bunch of processing and then draws it and a load of stats onto the framebuffer 320x240, then fwrites that to /dev/fb1. It requests frames from rawcam at 50 fps.
I had a noticeable drop in the FPS I could process at after moving the code to a pi zero w. To write this code I did as others have and cloned raspiraw then changed it to my needs. I didn't change any of the options in the build script and having just looked GCC optimisations are off. Anyway bumping up the GCC optimisation fixed my performance problem, so anyone doing a lot of looping through pixel arrays using raspiraw based code and having an issue with speed check the -OX option in ./buildme.
I got 16 FPS with the default setting -O0 up to 48 FPS with -O2 or -Ofast, quite a massive improvement! This is on a PZW with wifi on and an ILI9341 SPI TFT 320x240 using the default raspbian fbtft device on fb1.
Here are the results of my particular app for different optimisation levels:
Code: Select all