Note: I have not looked recently to see if Frank's code has been updated to handle refreshOnce to actually only update once... More in a minute.
Continuous versus one shot. As for overhead someone like Paul understand this a lot more than I do. There may be some delays in memory access due to multiple pieces of code trying to access RAM at the same time. I believe there are two ports? into memory that can access at the same time, I think that is why adding the DMAMEM key to memory may help at times to move it into higher memory and maybe more likely to use the other port which is less used... Probably did not explain very well.
For me: refresh continuous vs Single is more interesting in the usage cases. that is if your usages is like a film where you can also update your data from top down and time it with the refresh, than the continuous works great. If however you have a usage case, where maybe you wish to update a portion of the screen, and maybe you do it in multiple steps, like fill rect to background and draw new image, or maybe restore a portion of image and draw new stuff. Then for me a refresh once works better.
That is for example if your code does something logically like: fillScreen(black), Draw field 1, draw field 2...
Then if you have continuous updates turned on, you may very likely see partial updates and flashes on the screen where example you see part or all of the screen as a result of the fill screen... So in these cases (for the most part all of mine), I prefer to be in control of when the update happens and use the single update.
Now about this library RefreshOnce... At least the last time I looked, the RefreshOnce actually refreshed twice, the first time while still in the main refresh function and a second time using DMA, so it was actually slower and more overhead than just doing a logical drawRect...
The reason: is that the setup code, needs to logically set things up, where, it may output something like:
<Set horizontal limit>,X1, X2, <set Vertical limit>, Y1, Y2, <write mem>, [here is where the screen data starts to output DMA]
With the above the <> fields are output with the DC asserted and the others are with the DC not asserted. In order to change the DC you need the data output in the PUSHR register to output the full 32 bits of data including the CS status, and then after that we output 16 bit values to PUSHR for the rest of the data...
Problem was how to update the DC bits and properly have our data in sync- Frank ran into this and the simplest way was to output the first screen using normal non DMA PUSHRs and when that finished then enabled the DMA output, which the first data word in the first of the DMA chains starts at the first pixel...
In my version, I did not want to do that... So I had to hack up my DMAChain such that the first Item in the chain started at the second pixel and then I only had to manually do the PUSHR of the first pixel, before enabling DMA. But then I had to handle the continuous case, so I added another element at the end of the DMA chain with only one pixel in it (the first one)...
Hope that makes sense?
Also maybe soon we can enable this code as well on T3.5? If we really do have more memory... And/or someday I might update my version where we can have dma backing for partial screens, that I can move around...