[gdal-dev] RE: progressive rendering

[Norman Barker]

Hi Tamas,

Looks like we are getting there in terms of defining the interface :-)
My comments are inline.



-----Original Message-----
From: Tamas Szekeres [mailto:szekerest at gmail.com] 
Sent: Wednesday, September 03, 2008 5:33 AM
To: Norman Barker
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

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:

<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