You're right, it didn't make it into the 1.3 release. There's one little glitch to work out, I think because I'm not stopping the circular DMA fast enough. I might need to switch to normal DMA but use the half-complete interrupt to do the same kind of pipelining.
Regarding your previous questions.. Why not prepare the entire update and send it out at once? Mostly just being stingy with memory. We'd need two copies of the command buffer since we'd want to update the next frame while the current is still being sent, so that's an extra ~28KB of the 320KB SRAM required. As far as overhead in the display driver, I'm not actually sure! In one sense it's the same as before, the difference is using the circular buffer lets us set up the command buffer at the same time DMA is running instead of bouncing back and forth between the two. We're not doing any less work, we're just doing it in parallel. But if you want to run at >48 fps, once this patch is out and the hardware supports it, you'll have to finish your work faster--by 10% in order to run at 54 fps.
We've been dealing with a lot of big structural stuff the last month or two, getting ready for season testing. I can't wait until I can go back to knocking off bugs and getting them easy dopamine hits.
I think the problem is we can't stop it right at the end of a row so a bit leaks through, putting an extra garbage line on the screen. I changed that back to normal line-by-line transfer but now I'm keeping the double buffer and pipelining it properly (fire off the transfer, then while that's going prepare the next line to send once it's done) and that gets us to an even 50 fps. Gonna call it there. 