This costly transformation is happening at
glBegin() time because that is when you ?¬?rst use the texture.
Figure 11-13 ptm1 OpenGL Statistics
Putting It All Together 239
Figure 11-14 ptm2 OpenGL Statistics
Please Tune Me 2
Moving on to ptm2.c, we??™ve remedied the texture type problem by replacing
GL UNSIGNED SHORT 4 4 4 4 with GL UNSIGNED BYTE. Again, we have twice
the storage requirements but the type is hardware native. Running ptm2 on our
test system, we see more than one frame per second: Not earth-shattering, but a
200 percent improvement at least over the performance of ptm1.
If we??™re going to shatter earths, we need to keep tuning. Figure 11-14 shows an
OpenGL Pro?¬?ler look at ptm2.
Notice that the landscape has changed profoundly. As you improve certain
areas of the code, other areas that were previously minor, such as the
glTexImage2D() call at 6 percent become signi?¬?cant. We??™ve reduced our
glBegin() hit to 39 percent, but now our glTexImage2D() call has ballooned
to 39 percent.We also have a new player in the list: glVertex2f() is weighing
in at 17 percent OpenGL time.
Please Tune Me 3
To address the glTexImage2D() problem we saw in ptm2.c, ptm3.c moves
the texture de?¬?nition logic out of the rendering loop and into the initialization
routine. In its place, we use texture binding. In effect, we??™ve replaced immediate
mode logic with retained mode logic.
Pages:
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353