[gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/29 Adam Nowacki <nowak at xpam.de>:
>
> 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