[Gdal-dev] C# Bindings

Tamas Szekeres szekerest at gmail.com
Sun Nov 5 11:23:33 EST 2006


> Tamas just did "IntPtr buf = bitmapData.Scan0".  I assumed Scan0 was
> a buffer in the bitmapData object, and that it was previously allocated.
> So there is no apparent copying of the buffer, or allocation within
> the rasterio.  I could be missing lots of stuff though.

Would RasterIO reallocate the underlying buffer in some cases? It would
bring in some further problems should be handled at the interface.

> >> How about supporting ReadBlock/WriteBlock? Would it be required?
> >
> > I think this is a pretty low priority.
> Calling ReadBlock and WriteBlock is now also discouraged for C
> and C++ applications.  I don't see any need to binding them in
> the swig wrapped languages.

The documentation says it is more effective than using RasterIO instead.
How should I understand this?

> > For convenience, it would be nice to have overloads that assume default
> > values for the last three parameters (bufferOffset, pixelSpace and
> > lineSpace) for the common case where we're not dealing with packed
> > buffers. In these cases, bufferOffset = 0, pixelSpace =
> > sizeof(datatype), and lineSpace = bufXSize * pixelSpace.
> The default should be all zeros and then values are computed internally.
> This should already be documented in the rasterio docs.

We can see it exactly. But for a conventional C# user it would be more
to select a proper function overload instead of taking care of the
expected default values.

> By the way, if there is a way of doing pointer arithmetic with the
> IntPtr, then I think you should avoid this BufOffset idea. It seems
> like a hack to me.

Unless we would use /unsafe code fragments it will require to recreate the
InPtr object. And it might be handled differently on a 64 bit platform.

> PS. I'm very excited by the progress on the c# bindings!  I made a
> feeble attempt at this some time ago and failed because I didn't
> know enough about c# and swig typemaps

Since was not an expert in using the gdal part of the interface so far, I really
appreciate Simon's work by making clear some of the aspects to me.
But I feel happy digging into it in more detail as I can see the
features in action.  :-)

Best Regards,


More information about the Gdal-dev mailing list