[Gdal-dev] C# Bindings

Tamas Szekeres szekerest at gmail.com
Sun Nov 5 14:54:58 EST 2006


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



More information about the Gdal-dev mailing list