PM
To: Norman Barker
Cc: Even Rouault; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman,
I'd require at least one more roundtrip to reach the final form before
placing a vote on this. I'm afraid not all of the comments have been
taken into account an
one the vote part
>> correctly - it of course has a +1 from me!
>>
>> My comments inline below;
>>
>> -Original Message-
>> From: Even Rouault [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, September 03, 2008 4:42 PM
>> To: Norman Barker
&
uault [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2008 4:42 PM
> To: Norman Barker
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] RE: progressive rendering
>
> Norman,
>
> just a very quick review of the latest state of the RFC after a quick reading
>
Message-
From: Even Rouault [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 4:42 PM
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman,
just a very quick review of the latest state of the RFC after a quick reading
of it...
- do
nks again for your thoughts.
>
> -Original Message-
> From: Tamas Szekeres [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2008 10:59 AM
> To: Norman Barker
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] RE: progressive rendering
>
> 2008/9/3 N
Hi Tamas,
Comments inline, thanks again for your thoughts.
-Original Message-
From: Tamas Szekeres [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 10:59 AM
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
2008/9/3 Norman
2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
>
>
> 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
] RE: progressive rendering
2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
> Hi,
>
> I have updated the RFC
>
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> To take in all of your comments, and I have added a comment about how
> this is a progre
2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
> Hi,
>
> I have updated the RFC
>
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> To take in all of your comments, and I have added a comment about how
> this is a progressive format driver, but is no longer asynchronous, and
> I am
, September 02, 2008 1:40 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Tamas Szekeres wrote:
> Hi All,
>
> Upon thinking about the issues I've been come up with previously, I
> consider the following approach could be implemented easily either at
&g
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Nowacki
Sent: Tuesday, September 02, 2008 1:40 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Tamas Szekeres wrote:
> Hi All,
>
> Upon thinking about the issues I've been come up w
Tamas Szekeres wrote:
Hi All,
Upon thinking about the issues I've been come up with previously, I
consider the following approach could be implemented easily either at
driver or at SWIG interface level. Requires a new class to be
implemented by the async IO supported drivers and a new additional
Norman Barker wrote:
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 th
Hi All,
Upon thinking about the issues I've been come up with previously, I
consider the following approach could be implemented easily either at
driver or at SWIG interface level. Requires a new class to be
implemented by the async IO supported drivers and a new additional
method should be added
2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
>
> Im trying to design a interface with lowest overhead possible. Driver doesnt
> have to keep its own buffer and later copy, received data can be directly
> dumped into user buffer.
>
Adam,
As I have noted in the previous post we cannot easily conside
2008/8/29 Even Rouault <[EMAIL PROTECTED]>:
> Tamas,
>
> The only thing that was in Adam's proposal and that I don't find in yours is
> that, when the RasterIO in async mode returns something valid, the user has
> no way to know which part of the buffer has been updated by the driver. Thus,
> it in
Tamas Szekeres wrote:
2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
In my proposal the user could:
1) LockBuffer()
2) display the current snapshot
3) UnlockBuffer()
4) sleep for 100ms ignoring the update messages (but
NextAsyncRasterIOMessage() still has to be called to get the GARM_COMPLETE
messa
Tamas,
The only thing that was in Adam's proposal and that I don't find in yours is
that, when the RasterIO in async mode returns something valid, the user has
no way to know which part of the buffer has been updated by the driver. Thus,
it introduces some extra cost for progressive image displ
2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
>
> In my proposal the user could:
> 1) LockBuffer()
> 2) display the current snapshot
> 3) UnlockBuffer()
> 4) sleep for 100ms ignoring the update messages (but
> NextAsyncRasterIOMessage() still has to be called to get the GARM_COMPLETE
> message)
>
Ad
Ill talk about my original proposal
(http://lists.osgeo.org/pipermail/gdal-dev/2008-August/018088.html)
instead of the one on trac
(http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support).
Tamas Szekeres wrote:
Honestly I didn't follow the observations that have turned the things
into
t 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:[EMAIL PROTECTED]
> Sent: Thursday, August 28, 2008 10:50 AM
> To: E
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 [mai
@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 rece
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
post again when the RFC is updated.
Norman
-Original Message-
From: Even Rouault [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 4:00 PM
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman,
In fact, Adam's proposal re
er like pattern is the simplicity for
> the user to use this library, they just add a listener and get updates.
>
> http://www.codeproject.com/KB/architecture/observer.aspx
>
>
> Norman
>
> -----Original Message-
> From: Even Rouault [mailto:[EMAIL PROTECTED]
> Sent: Wednes
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman,
I've seen your answers to my question on the wiki.
So, if the call is not blocking, it means that the callback will not be called
back in the thread of the caller, but by a thread c
Norman,
I've seen your answers to my question on the wiki.
So, if the call is not blocking, it means that the callback will not be called
back in the thread of the caller, but by a thread created by the driver. That
might be a problem, as many bad things can happen then if the dataset is
calle
-dev] RE: progressive rendering
Another question :
how will that work with the block cache mechanism ?
If GDALDataset::RasterIO() is overloaded by the driver, the block cache will
not be used.
Not sure if it is a problem, but that might be interesting to think about that.
I've the feeling
Another question :
how will that work with the block cache mechanism ?
If GDALDataset::RasterIO() is overloaded by the driver, the block cache will
not be used.
Not sure if it is a problem, but that might be interesting to think about
that. I've the feeling that this is a bit linked to how the
Norman,
as I see you are currently editing your proposal and I've not yet made my
comments, here I go.
I would like that the dataset object to be added as the first argument of the
callback, and a void* user_data to be added as the last argument
So the call would be :
ds->RasterIO (GF_Read, x
nd at the moment I am leaning towards that.
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Nowacki
Sent: Saturday, August 23, 2008 6:08 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote
Norman Barker wrote:
I have created RFC 24 on
http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
I'd suggest creating completely new interface for this.
Why is this better (imo):
- application decides when and how ofter the updates occur, minimal
threading issues
- clearly define
2008/8/21 Norman Barker <[EMAIL PROTECTED]>:
> Tamas, Frank, all
>
> I have created RFC 24 on
>
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> for comment; hopefully the likes of mpg, simboss and others will chip in
> as well.
>
> Currently we are just defining an interface -
, 2008 3:45 PM
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote:
> Mainly it is either end of response, image done, or window done to
> indicate that there is a buffer update and the display should be
> updated, anything
2008/8/19 Norman Barker <[EMAIL PROTECTED]>:
> Tamas,
>
> Thanks for the input, much appreciated since I would like to get this
> interface defined.
>
> A streaming driver so JPIPKAK for example would need to register as its
> own driver to handle urls of the type jpip://, similarly ecwp would need
Hi Frank,
-Original Message-
From: Frank Warmerdam [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008 3:45 PM
To: Norman Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote:
> Mainly it is either end of response, image done,
Norman Barker wrote:
Mainly it is either end of response, image done, or window done to
indicate that there is a buffer update and the display should be
updated, anything else can pretty much be ignored.
Ideally the callback should indicate the region that has changed, since
the server is ent
@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote:
> Having spent some more time on this, is adding progressive support to
> gdal as simple as overloading the RasterIO function
>
>
http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a057
&
Norman Barker wrote:
Having spent some more time on this, is adding progressive support to
gdal as simple as overloading the RasterIO function
http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a057
43
and adding a callback function? I would like to standardize this if
possibl
@lists.osgeo.org
Subject: Re: [gdal-dev] RE: progressive rendering
Norman,
It seems like adding a GDALProgressFunc like parameter to RasterIO
would be a solution but I'm not totally sure about the negaive effects
of this change since these functions are frequently used.
Most of the drivers are
Norman,
It seems like adding a GDALProgressFunc like parameter to RasterIO
would be a solution but I'm not totally sure about the negaive effects
of this change since these functions are frequently used.
Most of the drivers are doing band based rasterIO so you should also
deal with Band.RasterIO
Having spent some more time on this, is adding progressive support to
gdal as simple as overloading the RasterIO function
http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a057
43
and adding a callback function? I would like to standardize this if
possible in the GDALDataset cl
43 matches
Mail list logo
