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:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 2:42 PM To: Norman Barker Cc: [email protected] 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
