[gdal-dev] RE: progressive rendering

[Tamas Szekeres]

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