Before trying to answer, I need to admit two things.
1: I've only read Kurt's code quickly, haven't actually worked with it or analyzed carefully
2: Obviously I don't know everything about FlexIO DMA, since I couldn't get hardware trigger working yet
Looks like Kurt's code is a using separate DMA transfer for each horizontal line. Two buffers and 2 DMA channels seem to be used in a ping-pong style. Actual hardware triggering from PCLK is done by XBAR. Since GPIO only supports 32 bit access, the full 32 bit register is captured into 1296 byte buffers. The DMA interrupt runs after each line, to extract the 324 bytes and set the DMA up again. It really looks like a pretty solid approach.
So far I've not tried to use interrupts at all. Hardly seems worthwhile to add all that until the hardware triggering issue is resolved.
But the general idea is pretty much as AN12686 describes. Rather than an interrupt after each horizontal line, FlexIO is meant to capture the entire image into the frame buffer and give a single interrupt when it's completed.
Kurt's code is using attachInterrupt() on VSYNC to set everything up. AN12686 suggests doing the same. The DMA config I used is meant to work that way. The main point is uses disableOnCompletion() which causes the DMA channel to not be able to work again until you enable it.
That's pretty much the opposite of how we do DMA for audio. For sound, the DMA is configured so it automatically restarts the same transfer all over again as soon as it's finished. The key ingredient to make that work properly is the TCD's SLAST or DLASTSGA setting. After the transfer is complete, the source or destination (whichever was accessing a buffer in memory) will be pointing to just beyond the buffer it used. These settings automatically add a constant to the source or destination pointer when the transfer completes. We use negative numbers, so the pointer goes back to the beginning of the buffer. If the DMA transfer is going to automatically restart, it better do so back at the beginning of the buffer its using!
So I believe those words in AN12686 are trying to say is you don't need to use those automatic adjustments, since the DMA is configured to not auto-restart. The code will just write the buffer address again when the rising edge of VSYNC happens. And if you were going to double buffer, I guess you would set the buffer address differently on each VSYNC rising edge.
Perhaps will try to use DLASTSGA with FlexIO for an auto-restarting transfer that doesn't require anything to be at the VSYNC rising edge? For single buffer, it could reset the destination so the DMA is ready to go for the next use. For double buffer, we could create 2 different DMASettings objects (like a DMAChannel, but only the transfer setup data, not actual hardware) and have each automatically load the other's settings after each transfer completes. If that's confusing, well, the other way to use DLASTSGA is scatter-gather, where a DMA channel can use DMA upon completion to completely replace all its settings. That's why we have a DMASettings class, so you can set up settings for a DMA channel to update itself when it completes. So 2 of those could be used with 1 DMAChannel that doesn't have disableOnCompletion() to create a double buffer approach that automatically restarts itself.
But having the DMAChannel disables on completion and an interrupt on the rising edge of VSYNC which programs the destination buffer and re-enables it is simpler and costs only a brief interrupt on VSYNC. Maybe eventually we'll go with DMA that automatically re-enables itself like we do for audio. But unlike audio, we have a lot of time between the end of a frame and the next VSYNC rising edge.
Hopefully that made some sense? Or at least didn't make it all even more confusing?