Hi Tamas, Looks like we are getting there in terms of defining the interface :-) My comments are inline.
-----Original Message----- From: Tamas Szekeres [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 5:33 AM To: Norman Barker Cc: [email protected] Subject: Re: [gdal-dev] RE: progressive rendering 2008/9/3 Norman Barker <[EMAIL PROTECTED]>: > Hi, > > I have updated the RFC > > http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support > > To take in all of your comments, and I have added a comment about how > this is a progressive format driver, but is no longer asynchronous, and > I am not sure how it ever could be asynchronous within the driver since > the methods block. It moves the thread handling to the user, which is a > fair trade-off over simplicity and abstracting some of the nastier > features of the protocol implemented. > I guess there's no need to maintain both ReadNextBlock and RasterIO in parallel only to choose the proper name for this function. I don't see why this function may not be asynchronous in effect. I consider the following operations would be implemented at driver level within this function: <ncb> It would be useful to maintain both ReadNextBlock and RasterIO in the case of JPIP, it can be advantageous (if the client can handle it) to call regions of a server image on tile boundaries -> ReadNextBlock, but in most cases I think RasterIO will be called. If you think it will just be easier to keep RasterIO then I am fine with that. </ncb> 1. Waiting for the next data to arrive, return if the user specified timeout have elapsed. 2. Update the user buffer and the iocontext according to the incoming data. If the data is ready to be rendered, then return immediately otherwise go to 1. In this regard the user thread is only blocked until a new data will arrive and the buffer contains valid data. When the caller then renders the display, new data may also be received at the driver so the next call to RasteIO may also return immediately. However - for example - in an 2D interlaced progressive rendering the driver should wait until the next turnaround of the image will arive completely before returning to the caller, since it's not too convenient to allow the user to render intermediary images that are not ready to display in the screen. <ncb> In comparison to a callback function, I think this behaviour is synchronous, we are blocking until a timeout, and then calling again for another time period even if it returns immediately. However this isn't a bad thing. </ncb> I consider moving the thread handling to the user is more beneficial than disadvantageous, since the user will have the freedom to choose the proper threading mode for their application. The user will have the freedom to spawn new threads if needed to call RasterIO, however I don't think it'll required in most cases. <ncb> I agree completely with this comment, sorry if I didn't make it clearer in the RFC. I think delegating the threading to the user language is a very good thing, it will certainly help with the Java swig wrappers and hence ImageIO which I am familiar with. </ncb> I don't think if the driver would be required to copy padding data into the user buffer since the user will be notified about the update region that should be copied over. <ncb> In the case of JPIP (however unfortunate) the server is allowed to adjust the region of the image returned this may require some padding the requested client buffer. Thanks again for the comments. </ncb> Best regards, Tamas _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
