kas1e's recent thread got me thinking about multiple buffering in general.
Being lazy and using WaitBVOP() got me a telling off from Piru and I now have the issue that my DisplayScreenBuffered class uses this approach, which I have confirmed is a CPU eater.
Looking at the documentation for "proper" multiple buffering, it seems there are 2 messages you should wait for. One to say that the display is safe to switch buffers and another to say that it's safe to use the BitMap.
I couldn't help noticing, in the graphics.doc documentation that you wait for the BitMap first, then you may render to it, then you wait again before you swap the buffers.
I need to implement Display::refresh() for my class and I am now wondering about the best way to do it.
I am thinking of using a high priority child task that handles the physical swapping of buffers and all the waiting where needed, that is triggered by the parent task when it calls refresh().
My idea is that the very moment the BitMap is safe to use again, the child task will signal the parent again so that the refresh() method can return immediately allowing processing to continue, whilst the child task waits for the 'safe to switch buffers' message.
So the general idea for this is
1) Child task is waiting for parent to signal it.
2) Parent calls refresh(), which sends signal to child task.
The refresh() method now waits for child task to signal back that the BitMap is free.
3) Child task wakens then waits for BitMap "safe to use" message from graphics.library. On receiving this message, signals parent task that BitMap is free. The refresh() method is now complete and can return allowing the parent task to carry on rendering.
4) Child task waits for "safe to switch buffers" message from graphics.library. On receiving this message, the buffer switch is performed.
5) Child task now goes back to sleep again (1).
Has anybody tried something like this?