From: rgooch@rp.CSIRO.AU (Richard Gooch)
Subject: Re: Animation with XPutImage()?
Organization: CSIRO Division of Radiophysics/Australia Telescope National Facility
Lines: 41

In article <1993Apr21.165310.14544@dsd.es.com>, pmartz@dsd.es.com (Paul Martz) writes:
> In article <1993Apr21.154620.16330@infodev.cam.ac.uk>, dcr@mail.ast.cam.ac.uk (Derek C. Richardson) writes:
> > Hi, I'm new to this group so please bear with me!
> > 
> > Two years ago I wrote a Sunview application for fast animation
> > of raster files. With Sunview becoming rapidly obselete, I've
> > finally decided to rewrite everything from scratch in XView.
> > I put together a quick test, and I've found that XPutImage()
> > is considerably slower (factor of 2 on average?) than the
> > Sunview command pw_rop() which moves image data from memory
> > pixrects to a canvas. This was on a Sparc IPX. It seems that:
> > (1) the X protocol communication is slowing things down; or
> > (2) XPutImage is inefficient...or both!
> 
> Using XPutImage, your source is maintained by the client and the
> destination is maintained by the server, thus you incur the overhead
> of transporting through whatever client-server communications
> mechanism you are using.
> 
> Is it possible for you to maintain your source images in pixmaps?
> These are maintained by the server, so copying them into a window is
> much cheaper.
> 
> Also make sure you are not sending any unnecessary XSyncs, or running
> in XSynchonize mode.

  If you need speed, and your client can run on the same host as the X server,
  you should use the shared memory extension to the sample X server (MIT-SHM).
  xdpyinfo  will tell you if your server has this extension. This is certainly
  available with the sample MIT X server running under SunOS.
  A word of warning: make sure your kernel is configured to support shared
  memory. And another word of warning: OpenWindows is slower than the MIT
  server.
  I have written an imaging tool (using XView for the GUI, by the way) which
  yields over 10 frames per second for 512*512*8 bit images, running on a Sparc
  IPC (half the cpu grunt of an IPX). This has proved quite sufficient for
  animations.

				Regards,

					Richard Gooch....
