Regarding render to texture

i am implementing render to texture concept and have doubt regarding scope of a FBOs. After i am done with glDrawArrays call on default FBO with render to texture, i am deleting texture and non default FBO. Then i am calling glReadPixels to read contents on default FBO. So, my question is am i doing it right i mean should i call readpixel before deleting FBO and texture?

What i was assuming that after drawing it on default FBO we dont need non default FBO and texture but later some developer of OpenGL told me i am doing some strange things in my application referring to above. Please help me to understand this.

Objects in OpenGL, neither buffer objects nor texture objects nor framebuffer objects, aren't scoped in the sense objects (also basic types like int, not only user-defined) are in C/C++. If you create a framebuffer object, it will not be destroyed until you explicitly do so with glDeleteFramebuffers() or by simply destroying the whole context. Note that the latter version of cleaning up isn't good practice, although contexts clean up after themselves.

[..]default FBO[..]

It drives me up the wall that you simply won't adopt correct terminology even after having beentold so repeatedly. I will make a final attempt by showing you what the OpenGL specification has to say about your mysterious default FBO:

Originally Posted by The GL Spec

Initially, the GL uses the window-system provided default framebuffer. The storage, dimensions, allocation, and format of the images attached to this framebuffer are managed entirely by the window system. Consequently, the state of the default framebuffer, including its images, cannot be changed by the GL, nor can the default framebuffer be deletedby the GL.

After i am done with glDrawArrays call on default FBO with render to texture, i am deleting texture and non default FBO.

Ok, let's make some sense out of this. First of all, here's the algorithm depicted in your sentence:

1) create a framebuffer object and attach a suitable texture as color attachment
2) unbind the FBO, render some primitives with glDrawArray into the default framebuffer
3) delete the FBO and the texture
4) read back contents of the default framebuffer
5) wonder what the hell just happened
6) goto 1

Honestly, that's what you say above. Does it make any sense? No, it doesn't. Here's what you were actually trying to do:

1) create a framebuffer object and attach a suitable texture as color attachment (and a depth attachment would be wise too)
2) bind and clear the FBO
3) render some primitives

IF rendering using texture is required:
4) unbind the FBO thus switiching back to the >>>>> default framebuffer <<<<<
5) clear the default framebuffer
6) bind the texture used as color attachment
7) render something to which the texture will be mapped
8) goto 2
ELSE
9) if not done yet, set the color attachment as the read buffer for read backs using glReadBuffer(GL_COLOR_ATTACHMENT_i)
10) read back texture (== color attachment) contents into system memory using glReadPixels
11) process data in some way
12) goto 2

As you can see, you neither need to delete FBO nor should you delete the texture object because otherwise there won't be nothing to read back from. You could delete the FBO because textures are separate objects and not affected by framebuffer deletion, but you'd have to re-create it for every frame which is simply wasteful. Plus, there are also ways of not even switching off the FBO at all when redering subsequent stuff but I think that's beyond the scope of your question.

Here are the steps i am following:
1) create a framebuffer object and attach a suitable texture as color attachment
2) bind and clear the FBO
3) render some primitives
4) unbind the FBO thus switiching back to the system FBO
5) bind the texture used as color attachment
6) Render on system FBO with texture created above.
7) delete texture and FBO created.
8) glReadpixel from system FBO.

Now, as i have rendered on system FBO and it. why do we still need that texture and other FBO which were used as textures?
@thokra : i guess you got my question wrong, i am not reading pixels from non default (other FBO created).
Please correct me if wrong.

Ok, it is just a terminology i am using to distinguish between two FBOs.

Yes, I realized that multiple threads ago. But the problem is that you call the other FBO the default FBO. There is no such thing. The only place where the word default can pop up when talking FBOs is turning FBOs off by binding 0 to the target. If you actually use two FBOs, simply call them FBO A and B or 1 and 2 or something. I never intended to be hard on you or something, I simply want to encourage you to use standard terminology that's correct and understood by everyone. Don't teach yourself incorrect things - old habits die hard.

I don't have any loop to render it again and again, i am rendering it only once.

Your intent wasn't clear at all when I read your question. Remember that most of the time people around here render more than a single frame. Please be accurate about what your application does.

If you're not destroying the GL context after rendering and there's a chance that you'll need to render later again, you don't need to. It's ok, but unecessary.

Nope, I doesn't make any difference for the purpose of reading back data. As soon as you rendered to FBO B or the default framebuffer, the texture isn't required anymore and so isn't the FBO. Plus, being thorough, you'd have to do cleanup when the GL context goes down. So you basically do what any good application does when it goes down.

Go easy on him. That's probably my fault. I like to call the default framebuffer the system framebuffer, window-system framebuffer, or whatever. No, it is not a framebuffer object, but you bind it just like it is (handle 0). So it's easy to lose the distinction.