Changes between Version 17 and Version 18 of rfc24_progressive_data_support

Timestamp:

Aug 27, 2008, 1:08:47 PM (16 years ago)

Author:

normanb

Comment:

--

rfc24_progressive_data_support

@@ -25 +25 @@
 [http://article.gmane.org/gmane.comp.gis.gdal.devel/16630/match=progressive+rendering Tamas Szekeres]
 
-Question: It seems we are tending to spawn new threads in every RasterIO operations at driver level, which is quite inconvenient 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?
+''Question'':
 
-Response: 
+It seems we are tending to spawn new threads in every RasterIO operations at driver level, which is quite inconvenient 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?
+
+''Response'': 
 
 There will one thread at the RasterIO driver level communicating to the server and this will be separate to application thread, the driver will accept new window requests from the application and change the requests being made to the server within the thread.  There is a degree of synchronization required here, but this is hidden within the format driver.
@@ -35 +37 @@
 pBuff will be small, it only contains the data for the currently request window at a particular resolution level and these are normally proportional, so small window implies higher resolutions, large window implies low resolution.  As such an initial version will provide a copy of the buffer rather than a pointer this should protect the buffer from corruption by multiple threads.
 
+''Question'':
 
+How will the intermediary data 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.
+
+''Response'':
+
+In step 5, GDALProgFunc(xOff, yOff, xSiz, ySiz, pBuf, bufXSiz, bufYSiz, bufType, nBandCount, bandMap, nPixelSpace, nLineSpace, nBandcount) specifies the region of the image (at base resolution) that has changed, the dimensions and type of the buffer, everything needed to render the buffer data.
+
+''Question'':
+
+Interchange between the dataset and band level functions:
+
+''Response'':
+
+This is the big question, since within jpip (and other streaming protocols) this is handled at the dataset level as opposed to the band level.
+