[gdal-dev] RE: progressive rendering

[Norman Barker]

Adam,

Thank you for your detailed reply, I am certainly considering it and I
will add it to the wiki for comment.  I will also be editing my notes to
take in Tamas comments.

I a couple of questions, I loosely based the callback function in the
RFC on the listener (observer) pattern
(http://en.wikipedia.org/wiki/Observer_pattern) which minimizes the
amount of client integration - with your proposal I can see that we need
the client to decide how often to update the screen this will require a
polling thread and a degree of synchronization with the data buffer
which imo result in poor display - the display could be blocky in
between updates rather than truly progressive.  With a callback function
the limiting factor is the refresh of the gui.  With the listener
pattern we can have multiple displays subscribe to the same source as
well (thumbnail, main etc.) - this is possible with your code too, but
the separation of events isn't there resulting in a master controller
function to decide who gets the updates.

Can you provide me of examples of the interface you propose working?  I
would like to consider it; coming from a java background the listener
pattern is pretty common and at the moment I am leaning towards that.

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: Saturday, August 23, 2008 6:08 PM
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

Norman Barker wrote:
> I have created RFC 24 on 
> 
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support

I'd suggest creating completely new interface for this.
Why is this better (imo):
- application decides when and how ofter the updates occur, minimal 
threading issues
- clearly defined synchronization points: NextAsyncRasterIOMessage(), 
LockBuffer(), UnlockBuffer()
- requests can be aborted with EndAsyncRasterIO();


class GDALAsyncRasterIOMessage {
   GDALAsyncRasterIO *asyncrasterio;

   void *userptr;

  // GARM_UPDATE, GARM_COMPLETE, GARM_ERROR, ...
   int what;

   int xoff, yoff;
   int xsize, ysize;
   // ...
};


class GDALAsyncRasterIO {
// lock a whole buffer
   void LockBuffer();

// lock only a block
   void LockBuffer(int xbufoff, int ybufoff, int xbufsize, int
ybufsize);

   void UnlockBuffer();
};


class GDALAsyncDataset : public GDALDataset {
   GDALAsyncRasterIO *AsyncRasterIO( /* same as RasterIO */ , void 
*userptr);

   void EndAsyncRasterIO(GDALAsyncRasterIO *);

// if there are no new messages return NULL if wait is false or wait for

new message if wait is true
   GDALAsyncRasterIOMessage *NextAsyncRasterIOMessage(bool wait);

   void ReleaseAsyncRasterIOMessage(GDALAsyncRasterIOMessage *m);
};




// ###############
//  How to use it
// ###############

GDALDataset *ds = GDALOpen( /* ... */, GA_ReadOnly);

// start asynchronous raster io, can have multiple running at same time
GDALAsyncRasterIO *r = ds->AsyncRasterIO(GF_Read, xoff, yoff, xsize, 
ysize, bufptr, bufxsize, bufysize, bufdatatype, 3, NULL, 0, 0, 0,
userptr);

while (...) {
   GDALAsyncRasterIOMessage *m = ds->NextAsyncRasterIOMessage(true);

   if (m) {
     if (m->what == GARM_UPDATE) {
// lock the buffer so there will be no updates while we read from it
       m->asyncrasterio->LockBuffer( /* ... */ );

// display updated region

       m->asyncrasterio->UnlockBuffer();
     } else {
// handle completion, display error message, ...

     }

     ds->ReleaseAsyncRasterIOMessage(m);
   }

}

ds->EndAsyncRasterIO(r);

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev