2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>: > > Im trying to design a interface with lowest overhead possible. Driver doesnt > have to keep its own buffer and later copy, received data can be directly > dumped into user buffer. >
Adam, As I have noted in the previous post we cannot easily consider this "direct" manner realizable, because many of the SWIG wrappers may have to copy the buffers between the target language and the GDAL core. To mimic this behaviour of the interface would require to keep the buffer at the API level which is almost equivalent as handling this at driver level. > > The RasterIO function has been there for years. Changing its behavior by > some hidden variable will definitely make it easier to use (or read) it the > wrong way. Im trying to protect programmer's foots :) > The behaviour wouldn't change accidentally only upon the user's explicit request. > > Being able to mix both blocking and async RasterIO calls sure would help to > 'progressively' upgrade code from RasterIO to AsyncRasterIO. > Opening 2 datasets would be a real bad thing: no shared cache. > Would the user be able to use both of the methods at the same time in the original proposal? >> I consider the IO context should be stored in the dataset as member >> variables by the driver. I don't see a pressing reason to support >> multiple raster IO operations at the same time with the same dataset. >> I think a similar operation could safely be utilized by creating 2 or >> more datasets and invoke their rasterIO simultaneously. >> In case if the user specifies a different buffer or image section in >> RasterIO then the driver would return with an error or gracefully >> initiate a new sequence to the server implicitly. > > Consider a simple image browsing app with a overview box in a corner. Having > 2 simultaneously running asynchronous raster io operations on the same > dataset would allow the driver to optimize requests to the server possibly > even eliminating separate requests for the overview. Or after zooming in the > previously cached data for main view could be used to service the overview > view. > Hmmm. It's quite difficult to imagine how the driver would operate to achieve this. I don't think if it's equal to copy (and resample) a region of a larger image than requesting the same region at the server in many cases. The subsequent user requests would less likely require the subset of an image in the same resolution and scale. Best regards, Tamas _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
