Not sure if we talk about the same thing. I see one renderer and one thread 
for each layer fetching the data (in the case of multiple layers to render). 

Especially in the case of a jdbc database, it is enough to fetch the first 
feature. This is the point where the "hard" work for the database engine is 
over and the jdbc result set is created. Further fetching is fast enoug. 

The fetching thread itself does not really much, only fetching the first 
feature. I see know problems here. 

Btw, we can use a thread pool for this. 

 

 

Jody Garnett writes: 

> Christian we cheat to get the same effect in uDig; multiple threads
> each with their own streaming renderer - and a shared label cache.
> Andrea has already ranted about the danger/direction of scheduling
> such threads in order to control disk load etc... 
> 
> Jody 
> 
> On Fri, Sep 25, 2009 at 6:15 PM, Andrea Aime <aa...@opengeo.org> wrote:
>> Christian Müller ha scritto:
>>> I think you are right here. Instead of collection prefetching, we should
>>> use multiple Threads for fetching data for multiple layers. Each layer
>>> fetches its data in an own thread.
>>> We had a short discussion about this, seems to be a matter of your
>>> resources.
>>
>> It's actually a matter of redesigning the renderer from the ground
>> up so that we can have multiple rendering streams progressing
>> together. Which yeah, I don't have the mandate to work on 
>>
>> Cheers
>> Andrea 
>>
>> --
>> Andrea Aime
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers. 
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel 
>>
 


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to