I’m doing an effect which requires copying the framebuffer to a texture (using glCopyTexSubImage2D) which is then drawn to a pbuffer for further processing, after which the result is drawn back to the framebuffer (by using the pbuffer as a texture).
The problem I’m having is that it is very slow (5fps). I’ve isolated the problem to this small sequence of events.
Do the copytexsubimage on framebuffer
Switch rendering context to pbuffer
Switch renedering context back to framebuffer.
Without doing ANY processing whatever (ie drawing nothing), just these 3 steps, my frame rate plunges to 5fps.
For an experiment I tried creating the pbuffer using the same GL rendering context as the window, but I found I couldn’t then make the pbuffer the current context. It seems the pbuffer MUST have its own GL Rendering Context (does anyone know if this is correct?).
The thing is, copying the framebuffer on its own without manipulating the pbuffer is very fast (~300fps). Also, manipulating the pbuffer on its own WITHOUT doing the copy is also very fast (~300fps). Doing both together is 5fps.
I’m using a ATi 9500 Pro with the catalyst 3.5 driver set.
isn’t it possible to avoid having to switch to pbuffer by rendering to the framebuffer, copy the texture. then render again to the framebuffer for further processing, copy the texture again and then render the final result to the framebuffer?
maybe you should explain what exactly do you want to achieve with this rendering technique.
if you need the pbuffer rendering result for manipulating the original framebuffer content (so it must not be erased by the second drawing step), you can render the second texture (that what you do with the pbuffer) to a DIFFERENT region of the framebuffer, altering the viewport with glViewport, so it draws to a different part of the screen.
maybe… I think one has to know what you are trying to achieve.
isn’t it possible to avoid having to switch to pbuffer by rendering to the framebuffer, copy the texture. then render again to the framebuffer for further processing, copy the texture again and then render the final result to the framebuffer?
maybe you should explain what exactly do you want to achieve with this rendering technique.
if you need the pbuffer rendering result for manipulating the original framebuffer content (so it must not be erased by the second drawing step), you can render the second texture (that what you do with the pbuffer) to a DIFFERENT region of the framebuffer, altering the viewport with glViewport, so it draws to a different part of the screen.
maybe… I think one has to know what you are trying to achieve."
Thanks for the reply JanHH.
The technique I’m doing involves repeated copying back and forth between 2 pbuffers many times to get the effect I want.
I can’t use the framebuffer as a scratch area as I need the original framebuffer intact as the final result of my technique is drawn on top of it.
[This message has been edited by rebelr6 (edited 07-27-2003).]
don’t use the pbuffer, but save the whole framebuffer to a texture with glCopyTexSubImage2D, render over this what before you did with the pbuffer, save contents again with glCopyTexSubImage, clear the framebuffer, render your texture back to it, then render your second texture over it, and start again, as many times as neccessary. might not be very fast but definitely over 5 fps, although I could imagine that the image gets too much smoothed by texture filtering if you do it often enough.