[gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/21 Norman Barker <nbarker at ittvis.com>:
> 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