[gdal-dev] RE: progressive rendering
nbarker at ittvis.com
Wed Aug 27 17:19:26 EDT 2008
Tamas, Even, all
Thank you for your detailed feedback, I have added a section to the RFC
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.
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 :
> 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
> 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
> - 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
More information about the gdal-dev