The following diff helps the cinematic playback speed in Q2/Q3 (which is
just a big texSubImage call each frame), but the other part of the problem
is the memory allocation and copying going on in unpackimage.

How reasonable would it be to allow properly formatted teximage/texsubimage
calls to bypass the unpacking stage?  Could the images be flagged and made
to reference the data in place when it is known to be ok, instead of
allocating/copying/freeing?

This would be a good general purpose optimization that would help a lot of
applications that pump a lot of texels through mesa.

John Carmack


Index:
teximage.c
=================================================================
==
RCS file: /cvs/mesa3d/Mesa/src/teximage.c,v
retrieving revision 1.7
diff
-u -r1.7 teximage.c
--- teximage.c  1999/10/21 12:45:03     1.7
+++ teximage.c
1999/10/21 22:38:34
@@ -1682,6 +1682,25 @@
             src += width *
texcomponents * sizeof(GLubyte);
          }
       }
+      else if
(image->Type==GL_UNSIGNED_BYTE && texcomponents==3 && image->Components ==
4 ) {
+         /* 32 bit (padded) to 24 bit case, used heavily by quake
*/
+         GLubyte *dst = destTex->Data 
+                      +
(yoffsetb * destTex->Width + xoffsetb) * texcomponents;
+         GLubyte
*src = (GLubyte *) image->Data;
+         GLubyte *stop;
+         GLint
j;
+         for (j=0;j<height;j++) {
+               stop = src + (width<<2);
+
                for ( ; src != stop ; ) {
+                       dst[0] = src[0];
+
dst[1] = src[1];
+                       dst[2] = src[2];
+                       dst += 3;
+
                src += 4;
+               }
+            dst += ( destTex->Width - width ) *
texcomponents * sizeof(GLubyte);
+         }
+      }
       else {

  /* General case, convert image pixels into texels, scale, bias, etc */

       struct gl_texture_image *subTexImg = image_to_texture(ctx, image,



_______________________________________________
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Reply via email to