On 4/11/05, Brian Paul <[EMAIL PROTECTED]> wrote:
> Simon Toedt wrote:
> > Has anyone yet looked into ways to improve rendering performance? I
> > have noticed that glXSwapBuffers() is slow (30secs +/-5secs on a
> > P3/600Mhz) and mainly spends its time in PsOutImageBytes() which calls
> > sprintf() in a tight loop:
> > (gdb) where
> > #0 PsOut_OutImageBytes (self=0x8c91ed0, nBytes=3, bytes=0xbfffec7d
> > "") at psout.c:1488
> > #1 0x080d63af in PsPutScaledImage (pDrawable=0x8a69eb0,
> > pGC=0x8c6f640, depth=24, x=0, y=0, w=9321, h=13431, leftPad=0,
> > format=2, imageRes=0,
> > pImage=0x4066e008 "") at PsArea.c:157
> > #2 0x080d6a79 in PsPutImage (pDrawable=0x8a69eb0, pGC=0x8c6f640,
> > depth=24, x=0, y=0, w=9321, h=13431, leftPad=0, format=2,
> > pImage=0x4066e008 "") at PsArea.c:332
> > #3 0x08291717 in XMesaSwapBuffers (b=0x4063d008) at xm_api.c:2391
> > #4 0x0828dca9 in __MESA_swapBuffers (glxPriv=0x8c6f178) at xf86glx.c:736
> > #5 0x0825a00f in __glXSwapBuffers (cl=0x8a69c60, pc=0x8c90a40
> > "\220\v\003") at glxcmds.c:1340
> > #6 0x082300ff in __glXDispatch (client=0x8a647b0) at glxext.c:435
> > #7 0x08083b69 in Dispatch () at dispatch.c:449
> > #8 0x0806a790 in main (argc=8, argv=0xbffff2a4, envp=0xbffff2c8) at
> > main.c:439
> > #9 0x400e48ae in __libc_start_main () from /lib/libc.so.6
>
> Well, at line 2391 of xm_api.c, XMesaXPutImage() is being called.
> That's a macro:
>
> #define XMesaPutImage(__d,__b,__gc,__i,__sx,__sy,__x,__y,__w,__h) \
> do { \
> /* Assumes: Images are always in ZPixmap format */ \
> (void) __d; \
> if (__sx || __sy) /* The non-trivial case */ \
> XMesaPutImageHelper(__d,__b,__gc,__i,__sx,__sy,__x,__y,__w,__h); \
> ValidateGC(__b, __gc); \
> (*__gc->ops->PutImage)(__b, __gc, ((XMesaDrawable)(__b))->depth, \
> __x, __y, __w, __h, 0, ZPixmap, \
> ((XMesaImage *)(__i))->data); \
> } while (0)
>
> The PsPutImage() function is an internal server function in the Xprint
> module. I have no idea why that would be getting called.
If the application uses the GL software renderer then PutImage calls
PsPutImage to push image dumps to the printer. If the Postscript GL
driver is used then vector data are generated from the 3D scene. Both
paths have their pro and cons... the software renderer has more GL
features and generates plain images, the Postscript renderer is
faster, generates scalable vector output but the Postscript code size
increases with the scene complexity.
Julien
--
Julien Lafon
Senior Staff Engineer, Hitachi
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
