[gdal-dev] RE: progressive rendering

Even Rouault even.rouault at mines-paris.org
Wed Aug 27 16:34:58 EDT 2008


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 

- Is the extended version of the RasterIO() call still blocking as the current 
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 

- 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

More information about the gdal-dev mailing list