[gdal-dev] RE: progressive rendering

[Norman Barker]

Frank,

Comments inline, I will refer mainly to JPIP (since this is what I know)
but this should hopefully apply to other streaming formats.  

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Tuesday, August 19, 2008 2:44 PM
To: Norman Barker
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

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?

<ncb>
In jpip, message response codes are used 

R=1 	Image Done
R=2	Window Done	
R=3	Window Change
R=4	Byte Limit Reached
R=5	Quality Limit Reached
R=6	Session Limit Reached	
R=7	Response Limit Reached
R=0xFF	Non Specified Reason	

Mainly it is either end of response, image done, or window done to
indicate that there is a buffer update and the display should be
updated, anything else can pretty much be ignored.  

Ideally the callback should indicate the region that has changed, since
the server is entitled to change the region it streams if the client has
requested an invalid ROI.

The callback isn't per scan line, but a whole window (at a particular
resolution level).
</ncb>

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.

<ncb>
The callback would need to include the x,y offsets, width, height and
resx, resy since otherwise there needs to be too much state
synchronization between the format driver and the client.  The simplest
would be to specify x,y, width, height at the base resolution of the
image and to use resx, resy to sample for the display implying the
buffer size.  The format driver would keep the cache.
</ncb>

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?

<ncb>
Definitely, this is the main objective.  A secondary objective is to use
the mechanism to download complete sections of a streaming image (so to
stream until a window done message) for use with gdal_translate for
example.
</ncb>

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.

<ncb>
I looked at AdviseRead, jpip is more progressive than this, an image
update is potentially available on every server read.
</ncb>

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.

<ncb>
I fully agree with this, lets get the interface right.  I don't think a
progressive interface would be cruft, but I agree that currently
applications aren't implementing this.  The wince port (and others) of
gdal to handheld devices may make this more useful and increase the
requirement for image streaming.

Many thanks,

Norman
</ncb>

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