[gdal-dev] RE: progressive rendering

[Norman Barker]

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: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Adam Nowacki
Sent: Tuesday, September 02, 2008 1:40 PM
To: gdal-dev at lists.osgeo.org
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
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev