[gdal-dev] RE: progressive rendering

Tamas Szekeres szekerest at gmail.com
Wed Sep 3 12:58:47 EDT 2008

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>


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>
> 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.

> 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?

Best regards,


More information about the gdal-dev mailing list