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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev