AGG changes for MapScript maintainers

[Tamas Szekeres]

Howard,

We should keep on using gdBuffer on the mapscript interface since it's
used in some other places to return array of bytes to the target
language. (Most of the languages have typemaps to do so)

In case of the imageObj and C# I had to reimplement 'gdBuffer
getBytes()' since returning arrays can safely be done by using
callbacks to the target language (In C#).

If I understand correctly you'd store that array internal to imageObj and use:
const unsigned char* msSaveImageBuffer(imageObj *img);
to return a reference to that array.

There are some drawbacks of this approach like:
1. We should make sure the contents of the internal array is kept
until it is used.
2. We should not use the function (and the imageObj) by multiple
threads simultaneously.

The main benefits are:
1. The array could be retained between multiple calls of msSaveImageBuffer
(We might use the msGetImageBuffer name instead)
2. There's no need to do extra copy when returning the array.
3. Auto destroy of the array on imageObj cleanup (in msFreeImage).

I would eventually support this idea since the benefits are more
signifcant. If you will implement 'gdBuffer getBytes()' in imageObj
accordingly, I'll easily transfer that implementation to the C#
related code.
I've recognized we have no test apps for this function in C# so I'll
create one, and I would also like to see the AGG stuff working with C#
as well.

Best regards,

Tamas


2007/8/14, Howard Butler <hobu.inc at gmail.com>:
> Tamas,
>
> Should we create our own buffer struct like the gdBuffer that is
> defined in mapscript.i, or should we add the necessary items to
> imageObj to support saving the unsigned char* data on that?  I see
> that imageObj.img currently has unsigned char *raw_byte (I think this
> is used for WCS) .  We would need to add a size_ptr to the img union
> (or use imageObj.size if that is appropriate) and an ownership flag
> to support MapScript.
>
> imageObj already contains a outputFormatObj, so with the additions to
> the struct, our call could look like:
>
> unsigned char* msSaveImageBuffer(imageObj *img);
>
> We then let msFreeImage take care of clean up.
>
> Look ok?
>
> Howard
>
>
> On Aug 12, 2007, at 4:13 PM, Tamas Szekeres wrote:
>
> > Howard,
> >
> > I would prefer the policy to keep any of the AGG/GD specific switches
> > inside the mapserver core if possible. In this regard we might want to
> > establish the corresponding renderer neutral functions like:
> >
> > unsigned char *msSaveImageBuffer(imageObj *img, int *size_ptr,
> > outputFormatObj *format);
> >
> > void imageFree(imageObj *img);
> >
> > The latter would wrap gdFree inside. As far as I can see currently
> > gdFree is used by both of the renderers. However in the future we'll
> > possibly have a renderer specific destroy function for the
> > corresponding image that'll make the things more complicated.
> >
> > Best regards,
> >
> > Tamas
> >
> >
> >
> > 2007/8/12, Howard Butler <hobu.inc at gmail.com>:
> >> Language-specific MapScript typemaps or specializations need to be
> >> updated to not exclusively use MapServer GD functions.  Previously,
> >> the default implementation of getBytes in image.i did:
> >>
> >> buffer.data = msSaveImageBufferGD(self->img.gd, &buffer.size, self-
> >>> format);
> >>
> >> Additionally, there is now an if test to check for the presence of an
> >> AGG driver and use the corresponding method to get the image buffer.
> >> If your MapScript language just uses getBytes for all of its buffer/
> >> image handling (other than the image.save() method which does not
> >> require any swig interface changes), you should be ok.  If you
> >> MapScript language has overrides or %extends of imageObj's methods,
> >> they will need to be updated to do the following in the case of an
> >> AGG format:
> >>
> >> buffer.data = msSaveImageBufferAGG(self->img.gd, &buffer.size, self-
> >>> format);
> >>
> >> I have updated some of the Python extensions (I do not have its
> >> image.write() done yet for AGG), and a quick browse showed at least
> >> C# with some overrides that need to be updated.  Java and Ruby too?
> >> Hopefully we can the necessary changes in before the next beta as
> >> more folks start testing MapServer 5.0 to make pretty pictures :)
> >>
> >> Howard
> >>
>
>