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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Nowacki Sent: Saturday, August 23, 2008 6:08 PM To: [email protected] 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 [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
