On Tue, Mar 16, 2010 at 4:31 PM, Frank Warmerdam wrote:
> With regard to the fixed vs. mixed resolution results, it is true
> that the current API provides no mechanism to request particular
> levels of completeness, such as passes in an interleaved progressive
> display. I imagine this issue was
Aron Rubin wrote:
Sorry to enter the discussion a little late here but I have a couple
of notes regarding the RFC. The RFC motion forced me to write this
quickly so I hope I get the points across.
1. The RFC is intentionally not callback/event oriented. You can
derive a non-callback/event versio
Sorry to enter the discussion a little late here but I have a couple
of notes regarding the RFC. The RFC motion forced me to write this
quickly so I hope I get the points across.
1. The RFC is intentionally not callback/event oriented. You can
derive a non-callback/event version from a callback/ev
Even Rouault wrote:
* I've skimmed the past discussions on RFC24 and I see one of your remarks
was "The GDALAsyncRasterIO object should be renamed GDALAsyncRasterReader or
something that does not imply that writing is supported unless that is
intended for the future". Perhaps that we can leave
Frank,
The API & concepts look good to me. I also agree with Tamas' remarks.
I think what Tamas means by synchronized wait approach is something based on
pthread_cond_new() / pthread_cond_signal() / pthread_cond_wait() for Unix or
CreateEvent() / SetEvent() / WaitForSingleObject() for Windows,
Tamas Szekeres wrote:
Frank,
The described approach with regards to the API seems reasonable for me,
I recall I took part in the conversation that time when the initial
version have been worked out, and I remember of most aspect.
Just by having a quick review of the code I have the following
Frank,
The described approach with regards to the API seems reasonable for me, I
recall I took part in the conversation that time when the initial version
have been worked out, and I remember of most aspect.
Just by having a quick review of the code I have the following
questions/concerns:
1. T
Folks,
I have spent several days working on the JPIP driver initiated by
Norman Barker, and also worked on by Garrett Briggs. This driver
uses a proposed new method for asynchronous and progressive data
access for GDAL. The driver now seems to be working fairly well, and
based on that work I ha
