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:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 2:44 PM To: Norman Barker Cc: [email protected] 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, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
