[gdal-dev] RE: progressive rendering

[Norman Barker]

Hi Adam, Tamas, Even, all

I have updated the RFC 

http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support

And completely changed the pattern used to reflect the general consensus
to use an asynchronous queue for communication between threads.

Can you comment on this, and let me know if it is acceptable?

Can we iterate this is a few times, and then how is this RFC approved
(or rejected!)?

Many thanks,

Norman 

-----Original Message-----
From: Adam Nowacki [mailto:nowak at xpam.de] 
Sent: Thursday, August 28, 2008 10:50 AM
To: Even Rouault
Cc: Norman Barker; gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering

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.