[Gdal-dev] C# Bindings

Frank Warmerdam warmerdam at pobox.com
Sun Nov 5 13:36:53 EST 2006

Tamas Szekeres wrote:
> Frank,
>> 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.


GDALRasterBand::RasterIO() does not reallocate the memory.

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

In theory, for some drivers, fetching the blocks directly can result in
slightly faster performance.   However, I now discourage this approach
with the possible exception of the most performance sensitive applications.

>> > 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
> affordable
> to select a proper function overload instead of taking care of the
> expected default values.

I'm afraid I don't understand what you are telling me.  I am
suggesting that you should pass zeros into the C++ RasterIO()
method when the no particulars are provided by the caller.  And
then the C++ computes appropriate values.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

More information about the Gdal-dev mailing list