[Gdal-dev] C# Bindings

[Tamas Szekeres]

Simon,

>
> I personally never use it, but it's a reasonable candidate for the
> future. It would allow you to fill the packed format Bitmap buffers
> we've been talking about with a single GDAL call, for instance, since
> you can read multiple bands at once into a buffer.
>
> I would suggest that we nail down the Band.Read/WriteRaster() methods
> first and then see where we are with the Dataset method.
>

Agreed.

>
> > Since I am not an expert in the usage of the GDAL part of the
> > interface it's much difficult for me
> > to think over the most efficient use cases. As you have mentioned
> > copying the buffers will produce
> > much of overhead during the processing of the image, I would consider
> > it was most efficient
> > to prolong the lifetime of the "processing" buffer by introducing a
> > new class (GDALBuffer for example)
> > This class could safely handle an internal unmanaged memory (being
> > allocated and freed at the unmanaged
> > side by using CPLMalloc and CPLFree). In addition we could use this
> > class passing the internal buffer to
> > WriteRasterInternal / ReadRasterInternal respectively. This class
> > would also contain the GDALDataType that makes up the
> > buffer and could reduce the number of overloads mentioned before in
> > this thread.
> > We could access the elements of the array using an indexer with a
> > GDALDataType
> > compliant C# type.
> > How do you like this idea?
>
> Hmmm, I don't think I really like it... :)
>
> We could create this new data structure and read and write data from it
> directly, but I would imagine that (a) indexing into this structure will
> not be as fast as indexing into an array, and (b) you're often going to
> want to copy the data into a proper array anwyay, for interoperability
> with other code that doesn't know anything about GDALBuffers. It just
> doesn't feel right to me...
>

Depends on how we are using the buffer most of the time.
I we would sequentially invoke GDAL with the same buffer and modify
a particular array item rarely it would be an option. Certainly, we could also
have the necessary Copy options between GDALBuffer and the
corresponding C# buffer.

>
> OK, how's this for a suggestion:
>
> We write Read/WriteRaster() methods for typed arrays that you've
> proposed, that use an intermediate buffer for copying. But in addition,
> we also write FastReadRaster() and FastWriteRaster() methods that use
> the "fixed" keyword to read/write directly to/from array buffers. These
> methods will be declared "unsafe". Code that we don't want to compile
> with /UNSAFE can just use the basic Read/WriteRaster() methods, while
> code that wants to achieve maximum efficiency can use the Fast/usafe
> variants of the method. Note that there's no actual difference in the
> safety of these methods!
>

Well, it's not so difficult to convince me. In this case we shall have to add
an option to sharp.opt and makefile.vc should be modified so as to
apply the /unsafe option conditionally and notify SWIG whether not create
the Fast.. methods. Disabling unsafe code would be the default option
if you don't mind.

Best Regards,

Tamas