[gdal-dev] RE: progressive rendering

[Frank Warmerdam]

Norman Barker wrote:
> Having spent some more time on this, is adding progressive support to
> gdal as simple as overloading the RasterIO function
> 
> http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a057
> 43
> 
> and adding a callback function?  I would like to standardize this if
> possible in the GDALDataset class.

Norman,

Can you comment on how you would expect the driver to update the buffer?

For instance, would you require a callback after each scanline?  Would it
be possible for the drivers to update the buffer one tile at a time?  Does
the callback need to clearly indicate what has changed in the buffer since
the last call to minimize screen areas updated?  Do you want to address
data that might be returned in interlaced format?

The simpliest case I can imagine would be passing (or installing) a
callback that drivers *could* call periodically to indicate that some
unspecified area of the RasterIO() buffer has been updated.

Is the main objective to be able to update stuff on the screen while a
buffer is being downloaded by JPIP or other slow access mechanisms?

I will note there was previously a different approach implemented.  That
was for the application to call AdviseRead() on the dataset to give the
driver a pre-clue to what region of interest will be accessed, and then
for the application to call RasterIO() on the desired region - often a
bit (ie. scanline) at a time.  This would give the driver advance information
on the area of interest (suitable to construct a single JPIP request),
and by accessing a line at a time the application gets the chance to
update things as they are received.

In actual fact though it was hard to implement drivers to take advantage
of this mechanism, and there was very little application level interest
in it.  So it has been essentially still-born - and I'd like to consider
deprecating and eventually removing GDALDataset::AdviseRead() from GDAL.

I will note that adding a callback to RasterIO() will result in
duplication of many interfaces since we need to preserve the old ones.
I'd like to ensure we do this "right" if we are going to do it since
we (GDAL) have a hard time getting rid of cruft once it's in a release
and gets into use.

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    | Geospatial Programmer for Rent