[gdal-dev] RE: progressive rendering

[Adam Nowacki]

Even Rouault wrote:
> I don't know JPIP, but I can image that the driver would start a thread when 
> AsyncRasterIO() is called. It communicates with the server and receives the 
> updates with a polling loop. When it has received an update,it put the 
> received data as well as the parameters describing the window, etc... in a 
> structure (let's call it a ticket), pushes that ticket in a stack and goes on 
> pushing tickets, or wait for the ticket to be consumed by the reader (both 
> are possible, even if you can't push continuously new tickets as memory will 
> increase, so the working thread would have to go in idle mode until the queue 
> decreases a bit)
> 
> The NextAsyncRasterIOMessage() call will check that some message is available 
> and unstack the first ticket. In fact, the LockBuffer() / UnlockBuffer() 
> could probably be avoided at the API level. Of course the implementation of 
> NextAsyncRasterIOMessage() needs an internal mutex to protect the accesses to 
> the queue.

My idea was to update the data buffer given to AsyncRasterIO immediately 
after receiving data and write only window coordinates into the queued 
messages. That way the queue will remain small, a few KB's at most. This 
is also why LockBuffer() / UnlockBuffer() is there, to protect the 
buffer from async updates while we read from it. LockBuffer(xoff, yoff, 
xsize, ysize) allows almost no wait operation if used with coords from 
queue.