invalidate framebuffer with front and back buffer

I have multiple calls which renders to different part of the default FBO with glScissor set to particular area but glViewPort to the whole screen. Now there are 2 cases front buffer and back buffer rendering.
If I invalidate color buffer before each draw call, it shows everything drawn on the screen with front buffer rendering. If I do back buffer rendering, it will show only last draw call’s contents.
Now, I use glClear only before very first frame so subsequent frames will have previous clearcolor. My scene is static to screen area, it means it will always be drawn to fixed part of the screen.

when I execute second draw call, what should be the contents of part of the buffer where i did first draw call? and why this behavior is different for back buffer and front buffer rendering?
One more thing, when i do front buffer rendering, while i am submitting calls for 2nd draw, display driver is scanning 1st draw’s contents.

I am using Mali device where I dont have a call to invalidate particular tile. With Adreno, we can use glstartTiling extension to specify tile’s dimensions and my code works with invalidate with front and back buffer.

When colors are written to the framebuffer, they are written into the color buffers specified by drawBuffer.If more than one color buffer is selected for drawing, then blending or logical operations are computed and applied independently for each color buffer and can produce different results in each buffer.Monoscopic contexts include only left buffers, and stereoscopic contexts include both left and right buffers. Likewise, single-buffered contexts include only front buffers, and double-buffered contexts include both front and back buffers. ShowBox Kodi Lucky Patcher The context is selected at GL initialization.

That doesn’t answer my question at all. Please read it again

It doesn’t make any more sense than the first time I read it. It might help to state the exact sequence of operations you’re performing.

But in general:

The contents of the front buffer become undefined whenever the OS feels like it. Overlapping windows, tooltips, etc may all destructively overwrite the front buffer.

The contents of the back buffer become undefined whenever you swap buffers. An implementation may simply copy the contents of the back buffer to the front buffer, leaving the back buffer unchanged. Or it may literally swap the buffers, so the back buffer is now what the front buffer used to be (and see the previous remark about the front buffer being modified whenever). Or it may make the back buffer into the front buffer then use some arbitrary chunk of memory for the new back buffer.

In short, if you want a buffer which doesn’t change unless you explicitly change it, you need to use a FBO. Or rely upon whatever guarantees a specific implementation provides regarding the default framebuffer (OpenGL itself doesn’t really provide any, except that the back buffer shouldn’t change unless you render to it or swap buffers).

debonair, it’s not clear what your problem is, what you’re trying to do to solve that problem, what 2 sequences of EGL/GLES calls you’re talking about, and what you hope to gain from them.

Please start with what describing clearly what your problem (or theory is). Then list your 2 EGL/GLES call sequences with comments to indicate what you suspect each should do (or the problem that they cause).

Just from what you have said, I would suggest reading about EGL_SWAP_BEHAVIOR in the EGL spec. And as GClements said, if you want complete control over what’s in your framebuffers, render to an FBO (and then just Blit to your EGL surface).