Re: xpm slow?

[Dave Lemke <>]

  From:  Mark Wedel <>
  Date:  Tue, 15 Mar 1994 20:15:30 -0800

   One thought I've had about pixmap creation is to change the way they
  are initially read.
  
   Instead of calling the XpmCreatePixmapFromWherever function for all
  2000 or so pixmaps, create a large montage of pixmaps (stored as something
  like crossfire.pix1, crossfire.pix2, etc.)  These would be something like
  a montage 20x20, or 25x20.  Exact size not really important, but it would
  be nice to be able to display them on one screen with sxpm, and an montage
  of all of them could really suck up a lot of memory in the load phase.
  Keeping these montages smaller solves that problem.

you'll also hit limitations on low-end devices (PC and Xterminals)
if you try to grab a huge contiguous chunk of memory.
  
   Then, when creating the pixmaps, the Xpm function only needs to be
  called once.  XCopyArea could then be used to copy a section off the
  montage pixmap into the small pixmap (likewise, there would also be a 
  montage of the pixmap clipmask).
  
   How crossfire does graphics right now is hardly what I call really
  optimized.  A lot of improvements could probably be made.
  
its a good idea.

i think looking into the XPM code is also a good idea.  i quickly
scanned it, and it looks like you can pass in the pixmaps with
actual pixel values, instead of color indices.  if so, crossfire
can pre-allocate the colors, munge the pixmap data, and then when
they're loaded there's no AllocColor calls.