Saving buffer contents after eglSwapBuffers

Question

I am implementing in Android and my own C ++ script for android using egl 1.1 . Android is currently using glSurfaceView - which allows me to draw on the back buffer that appears at the end of "onDrawFrame" - when replacing the back buffer and front buffer.

My problem with this is - I need to be able to display the back buffer and keep writing as if I weren't swapping. The reason for this requirement is that the scene is very large , and the construction of each frame is impossible, and does not wait for the end of the drawing - since the user will have to wait too long.

In other words - I need to create a scene gradually . At some point during the rendering, I decide the time, and I call eglSwapBuffers , which displays the reverse content from the back buffer, but when I continue to write, I write to the "old front buffer" that is missing sync .. (not containing things that I have done so far).

As far as I can see, the only option is to copy the back buffer before replacing. pseudo:

• Drawing back.
• Copy Back Buffer to temp Buffer
• Exchange
• Copy temporary buffer to (new) buffer back
• Draw extra buffers.
• And so on...

My question is: is there a way to follow steps 2.4?

• glCopyPixels useful in this case? Example?
• Is glBlitFramebuffer ?

Or am I not mistaken in this?

What I have already done:

• I tried to set EGL_SWAP_BEHAVIOR to EGL_BUFFER_PRESERVED , but it only works on certain devices (as described in the cron notes ):

Some surfaces allow applications to control whether the contents of the color buffer are preserved.

• Re-rendering the scene in each frame is not possible. I have read many times that this is recommended.

Answer 1

Your general approach is correct. Using glBlitFramebuffer() is likely to be more useful since glCopyPixels just copies some sub-rectangle of the buffer to a position in the same buffer.

However, I can think of a potentially better approach, at least if OES_framebuffer_object is available:

• draw texture or custom render buffer
• render texture BACK buffer / blit renderbuffer to BACK buffer
• swap
• update texture / renderbuffer
• render texture BACK buffer / blit renderbuffer to BACK buffer
• swap
• [... and so on...]

Thus, you do not have a copy / update / copy / replace cycle with 2 copies per frame, but only update / copy / swap with one additional copy.