2008/8/21 Norman Barker <[EMAIL PROTECTED]>: > Tamas, Frank, all > > I have created RFC 24 on > > http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support > > for comment; hopefully the likes of mpg, simboss and others will chip in > as well. > > Currently we are just defining an interface - but I am certainly > interested in coding the driver (and probably will) as well. >
Norman, Just some quick notes, I've read this over but I'm still dubious about the issues have been manifested earlier in this thread, namely: 1. It seems we are tending to spawn new threads in every RasterIO operations at driver level, which is quite uncovenient at the moment, therefore it should be considered with care. Will you allow RasterIO to be re-entered from the GDALProgFunc event handler or by another thread? Will you provide a copy of pBuff in GDALProgFunc or the same pointer will be passed back to the caller? How this buffer will be protected from the simultaneous access of the multiple threads? 2. How the intermediary data will be represented in the buffer required by the various kind of rendering methods? Will the user re-read the whole buffer in every roundtrip, or a subset of the data will be definied that have been changed in the meantime? I guess some cases only the modified scanlines or reduced resolution images would be sufficient to read. 3. Interchange between the dataset and band level functions. 4. Supporting the the current synchronous mode in addition to the asynchronous rendering mode. 5. With regard to the SWIG / C API would this be supported by means of adding a new function name to the API like GDALBeginRasterIO or GDALAsyncRasterIO for instance? > If JPIP means nothing to you then check out http://iasdemo.ittvis.com > and in the interest of fairness have a look at Lizardtech, Erdas and > Kakadu as well! > Would this driver be an extension or a replacement of the currently existing JP2KAK implementation? I can see some kind of support inside for JPIP as well however I'm not sure if it is fully functional. Best regards, Tamas _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
