was a larger discussion about mapserver development

[ender at titan.lab.csuchico.edu]

Steve,

  Instead of searching for a new image/graphics library, we can just
adapt the currently used one.  gd has a very open license, and is quite
easy to extend, only requiring major changes in the getpixel and setpixel
functions, as well as replacing all of the color allocation,
deallocation, and matching functions.

  I have re-written much of the library (in it's 1.2 incarnation) to
support 24 bit color ( and am extending it to 32 bit as time permits).  I
also took a polygon renderer from Michael Abrash's computer graphics book,
and adapted it for use with the library.  I haven't really looked at the
new polygon rendering code, but since it seems to work just fine, I don't
think that it would take much modification to update my code using the new
gd.
  
  Using the standard graphics libraries, it will be simple to include any
graphics type (with the appropriately named world file) as a base image.
I currently have jpeg and tiff supported, but including other formats
would only take a few hours to learn the library api.

  I have also used libttf with my code, and it works quite well.  I
haven't looked at the new gd ttf code yet, so I cannot say how much work
it will take to get it all up to date.

  I am going through the code right now, adding the correct references to
code sources, and will send it to this list in a few days.

  BTW, In order to merge better with some of the other projects I have
been working on, I have written my version in C++, but it can easily be
rewritten to use the standard c gd function calls again.

-Aaron Stafford
Geographical Information Center
California State University, Chico

On Wed, 29 Sep 1999, Stephen Lime wrote:

> It is reasonable to switch image/graphics libraries. Problem is there aren't many
> alternatives. Again, if anyone has other information please let me know.
> 
> Any readable format isn't real useful for live applications. One could easily
> extend the mapserver to read Arc generate files natively, but the cost would
> be used. ASCII files are much slower to read than binary and contain no indexes
> so the whole file must be processed rather than bits and pieces. 
> 
> Steve
> 
> >>> Nathan Carr <ncarr at guideguide.com> 09/29 1:19 PM >>>
> Stephen Lime wrote:
> 
> > I've looked for alternatives to GD and haven't found much. Actually ImageMagick has GD-like 
> > functions but the price is steep as the author reports 4x speed decrease. Perhaps this is an area 
> > you could contribute, sound like you must have solved the problem. Again, speed is critical.
> 
> I suppose this rules out GTK then.
> Is it plausible to have swichable image libraries?