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: 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. 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. 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. Best regards, Tamas _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
