There are lots of discussion about which is best to use for dynamic textures, pbuffers for compatibility or FBO for ease of use. Here's a dialogue from Elias Naur (Oddlabs and LWJGL developer) about the pros and cons:
I can't comment on performance, since our textures are generated once at load time. However, generating textures once presents a problem with render-to-back-buffer because of the pixel ownership test, which basically allows the
OS to not render pixels obscured by other windows.
Pbuffers are much harder to use than FBO and includes a context switch (as you know), but most complexity is hidden in LWJGL and they're supported by most cards. Notable exceptions:
Linux w/ATI cards have never implemented them.
Sucky drivers like SiS can pretend they have them but crash when you try to use them.
A bug in the latest vista ati drivers make Pbuffer.isBufferLost() always return true. We've reported it and it should be fixed at next catalyst release.
FBOs are nice (we recently implemented support for FBOs as a workaround for the vista ati issue), but they fail under some circumstances too:
render buffers doesn't seem to work as well as render-to-textures, so prefer render-to-texture even if you need the pixel data only and not the texture
-
it seems that some customers complain that TT crashes with FBOs when it worked fine before with pbuffers only (we try FBO first, then pbuffer, then back buffer), and some have reported that loading times have increased a lot, indicating that fetching FBO data is quite a lot slower than pbuffer fetches
(Note TT refers to Tribal Trouble, the first game from OddLabs)
