Hi, I have updated the RFC
http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support To take in all of your comments, and I have added a comment about how this is a progressive format driver, but is no longer asynchronous, and I am not sure how it ever could be asynchronous within the driver since the methods block. It moves the thread handling to the user, which is a fair trade-off over simplicity and abstracting some of the nastier features of the protocol implemented. I am not really a c++ developer (please do point out any stupid errors I may have made), but have written JPIP server and clients (in Java) and think the design (which in the main has come from Adam, Tamas, Even - not me) is a good (and a simple) one. It would be relatively easy to implement, I added the papzOptions to the method call as a general catch all for format implementations. Please direct your comments and improvements to specific items within the RFC so that it can be shaped to something that can potentially be approved and hence implemented. Many thanks, Norman -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Nowacki Sent: Tuesday, September 02, 2008 1:40 PM To: [email protected] Subject: Re: [gdal-dev] RE: progressive rendering Tamas Szekeres wrote: > Hi All, > > Upon thinking about the issues I've been come up with previously, I > consider the following approach could be implemented easily either at > driver or at SWIG interface level. Requires a new class to be > implemented by the async IO supported drivers and a new additional > method should be added to the GDALDataset and GDALRasterBand. > The user could implement the async IO by using the following pseudo sequence: > > <Code> > ... > </Code> I like it :) typedef enum { ..., CE_Again = 5 // timeout, buffer not updated, call RasterIO() again } CPLErr; typedef enum { // Async raster io status GRS_Complete = 0, // raster io is complete, call to GDALRasterIOContext->RasterIO() will return CE_Failure GRS_InProgress = 1, // raster io in progress, call GDALRasterIOContext->RasterIO() to get more data GRS_Error = 2 // error, call to GDALRasterIOContext->RasterIO() will return CE_Failure } GDALRasterIOStatus; typedef enum { // Hints for GDALRasterIOContext->RasterIO(), driver implementations may ignore any or all GRH_SingleBlock = 0x1, // exit after single block update, even if there is more data immediately available GRH_Progressive = 0x2, // update with lower resolution data / fill with interlaced rows GRH_WaitForTimeout = 0x4 // wait for timeout even if already updated some data } GDALRasterIOHint; class GDALRasterIOContext { public: GDALRasterIOContext() { eStatus = GRS_Continue; pszError = NULL; } public: // Continue raster io, update pData buffer with new data, nUpdate??? = bounding box of all updated blocks // return CE_None if updated with new data // return CE_Again on timeout // return CE_Failure on error virtual CPLErr RasterIO(void *pData, int nTimeoutMilliseconds = -1, int nHint = 0); public: GDALRasterIOStatus eStatus; char *pszError; // if eStatus == GRS_Error this should contain human readable error message, NULL otherwise int nUpdateXOff; int nUpdateYOff; int nUpdateXSize; int nUpdateYSize; }; class GDALDataset { ... public: virtual GDALRasterIOContext *StartRasterIO( GDALRWFlag eRWFlag, int nXOff, int nYOff, int nXSize, int nYSize, int nBufXSize, int nBufYSize, GDALDataType eBufType, int nBandCount, int *panBandMap, int nPixelSpace, int nLineSpace, int nBandSpace ); virtual void EndRasterIO(GDALAsyncRasterIOContext *poContext); }; _______________________________________________ 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
