[gdal-dev] RE: progressive rendering

[Norman Barker]

Hi Tamas,

Comments inline, thanks again for your thoughts.

-----Original Message-----
From: Tamas Szekeres [mailto:szekerest at gmail.com] 
Sent: Wednesday, September 03, 2008 10:59 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>:
>
> <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>
>

Norman,

I don't see the difference between the functionality of ReadNextBlock
and RasterIO. I guess it was only a name change when Adam have renamed
my ReadnextBlock to RasterIO and I didn't object to it.
Can you explain a possible difference from the aspect of the JPIP
driver.
I admit the rasterIO region have already determined when
CreateRasterIOContext have been called. I think we cannot safely
change these parameters within the same IO context.

<ncb>
Isn't there a function in GDAL to get the most appropriate block size,
it will certainly be possible to advertise this through JPIP. Whereas
with RasterIO you could specify a region that covers many blocks.  Again
I defer to you on this, we can make it simple and just keep the one
function.
</ncb>


>
> <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 the blocking will occur until that time when a valid update
is ready to be rendered by the user. In the meantime the user won't
really be able to render anything so I guess waiting here is not a big
issue. However if you would support the user to do any other thing
within this thread, then implement to return immediately when the
timeout is set to 0. Then status= IO_PENDING will show that there's
nothing new can be found in the buffer and RasterIO should be called
again soon.

<ncb>
Ok, I have got it now - we have a polling thread on the status - sounds
good to me.
</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.
>

Hmmm... That's difficult for me to follow. Won't it result in ugly
effects in the image display?

<ncb>
It can result in ugly effects on the display, however those 'ugly'
regions will be filled with subsequent requests to the server.  It is
part of the JPIP spec. so I mentioned it.

Many thanks.
</ncb>

Best regards,

Tamas