RTMBindOrCopy will attempt to bind the texture directly to the framebuffer if the driver supports that, and fail back to RTMCopyTexture if it doesn’t.
Binding the texture to the framebuffer means the texture shares the same graphics memory as the framebuffer. When you render the frame, you are directly rendering to the texture, and no copy operation is required. It’s a tiny bit faster because you avoid the need for the copy.
The only downside is that the texture is permanently associated with the buffer; if you disassociate the texture from the buffer, you lose the texture data too. In RTMCopyTexture, the texture has its own memory that it keeps whether it is attached to a buffer or not.
Another option, instead of using RTMCopyTexture, is to go ahead and use RTMBindOrCopy, but take the texture and the buffer out of the chain when you want to keep it around. Create a new texture and buffer to replace it in the chain. You’ll have to keep the buffer around for as long as you need the texture, potentially wasting even more graphics memory (especially if Panda ended up failing over to the copy operation anyway), but you don’t have to monkey with the internals of the FilterManager.
David