[gdal-dev] RE: progressive rendering

[Norman Barker]

Tamas, Even, all

Thank you for your detailed feedback, I have added a section to the RFC

http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support

Which takes each of your questions and provides a response, please comment further - it is a great help. 

I have added the questions to the RFC since I want to capture them for reference as they raise good points.

Adam, as mentioned in an earlier email, I am considering the interface you propose can you provide me with examples of it working - currently I am sticking as close to a traditional pattern as I can.

I would like to get this interface defined and approved, so that format drivers for streaming data can be written.

Many thanks,

Norman  

-----Original Message-----
From: Even Rouault [mailto:even.rouault at mines-paris.org] 
Sent: Wednesday, August 27, 2008 2:42 PM
To: Norman Barker
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

Another question :

how will that work with the block cache mechanism ?

If GDALDataset::RasterIO() is overloaded by the driver, the block cache will not be used. 
Not sure if it is a problem, but that might be interesting to think about that. I've the feeling that this is a bit linked to how the modified
RasterIO() on the dataset works with the RasterIO() on the band.


Le Wednesday 27 August 2008 22:34:58 Even Rouault, vous avez écrit :
> Norman,
>
> as I see you are currently editing your proposal and I've not yet made 
> my comments, here I go.
>
> I would like that the dataset object to be added as the first argument 
> of the callback, and a void* user_data to be added as the last 
> argument
>
> So the call would be :
>
> ds->RasterIO (GF_Read, xOff, yOff, xSize, ySize, NULL (1), bufXSize,
> bufYSize, bufType, nBandCount, bandMap, nPixelSpace, nLineSpace, 
> nBandSpace, pfnProgressIO, pProgressUserData)
>
> typedef (*GDALRasterIOProgressFunc) (GDALDatasetH hDS, int xOff, int 
> yOff, int xSize, int ySize, void * pBuf, int bufXSize, int bufYSize, 
> GDALDataType bufType, int nBandCount, int* bandMap, int nPixelSpace, 
> int nLineSpace, int nBandSpace, void* pProgressUserData)
>
>
> I've a few questions so that your explanations and proposals are clear 
> to my mind.
>
> - Is the extended version of the RasterIO() call still blocking as the 
> current version?
> My understanding of the discussion is "yes", but I would like a yes/no 
> confirmation. If "no", then I don't understand at all how it can work.
>
> - What happens if the user specifies a not NULL argument as the output 
> buffer ( in (1) ) ? What happens if the user specifies GF_Write ?
> It is probably an argument for a name change, something like 
> ProgressiveRasterIO.
>
> - Is it guaranteed that the bufType, nBandCount, bandMap, nPixelSpace, 
> nLineSpace, nBandSpace specified by the caller will be the values 
> passed to the call back function ?
>
> - Maybe it can make sense to add some way of cancelling the whole 
> RasterIO call by providing a callback, like the standard progress 
> callback (GDALProgressFunc in gdal.h) mechanism do ? Because the 
> RasterIO() will spend most of the time waiting for data. It could 
> resume from time to time to call that callback and see if the user 
> still wants the request to be continued. It would be nice if the 
> mechanism could provide some percentage of the total progress as it might be tedious for the user to compute that ?
> But that's probably not easy to define if you first update the whole 
> request area with a low resolution, and then at higher resolutions.
>
> - What happens if the user issues another call to RasterIO(), 
> traditionnal version and/or your extended version, in the 
> pfnProgressIO callback ? Is it forbidden, or does the answer depend of the underlying driver ?
>
> Best regards
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev