Take the 2-minute tour ×

Instead of using multiple framebuffer objects, can I also create only one and achieve the same results by switching it's target texture when needed?

  • Is this a bad idea in all cases? If yes, why?

I've been implementing a function render.SetTargetTexture() in my program's API, and logically it wouldn't work if there were more framebuffers used behind the scenes. I'd have to fully expose framebuffers then.

share|improve this question
I've never actually benchmarked this, but it seems kind of conclusive that binding a different FBO is more efficient. Binding a different texture to the FBO requires complicated consistency checks for framebuffer completeness (if not explicitly by you, then in any case inside the driver). Binding a different, unmodified framebuffer doesn't require that kind of thing. –  Damon Jun 21 '11 at 22:59
I think another way to look at it is it probably doesn't matter. I don't know of any apps that switch targets thousands of times per frame. Most switch just a few times max. I agree that switching fbos should be faster than switching attachments but if it doesn't really matter than your API is fine. –  gman Jan 27 at 5:19
add comment

1 Answer

A FBO itself is just some logical construct, maintained by the implementation and it will consume only the little memory that its parameters require. The main purpose of a FBO is to have an object that maintains a consistent state.

Whenever you do changes to a FBO's structure, the implementation must check for validity and completeness. The OpenGL specification doesn't say anything about the complexity of this operation, but it's safe to assume that changes to a FBO's structure is about the most time consuming operation (maybe by a large margin).

Since the FBO itself does not consume noteworthy memory, only the attachments take memory, which are independent objects, allocating multiple FBOs and swithing those is what I recommend.

share|improve this answer
add comment

Your Answer


