[gdal-dev] RE: progressive rendering

[Even Rouault]

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