First, our draw routines are the same as the
FBO example, so we won??™t present them again. The ?¬?rst method draws the stuff
to be used as a texture, and the second draws the scene using the texture generated
from the ?¬?rst method. Second, there is no binding or other redirection of
where this routine renders. Instead, we do all of the rendering in the back buffer,
and then copy it to a texture. This approach has one important implication: This
technique really works only for double-buffered visuals.
Another consequence of the way this technique works is that we??™re actually
copying the contents of the back buffer to a texture, so performance may be less
than that in the FBO case. Speci?¬?cally, we perform this copy between each of
the[ self draw* ] methods. Thus performance is likely to be slower than in
the FBO case, but there??™s a lot of bandwidth available in modern graphics hardware,
so if you can spare it, this technique will be pretty ef?¬?cient. But the reason
we??™re explaining this method at all is that the hardware on which you run potentially
might not support a real off-screen technique like FBO, so a technique
like render-to-texture may be required.
And that brings us to the ?¬?nal point: This technique is window-dependent.
You??™ll notice that we??™re copying only a ?¬?xed area of pixels from within our
drawing surface in our example. If we wanted to capture the entire area, we??™d
have to monitor the size of the drawable area (using the reshape routine) and
ensure that the width and height of the copy call were updated accordingly.
Pages:
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253