Andrea Aime a écrit :
>> Well, regarding the caching itself, our current approach (which is now
>> still only implemented in a different project in C++) is to cache the
>> original geometries (not the decimated ones) in blocks of data according
>> to a spatially indexed tree constructed only once on first access for
>> each layer/FeatureSource. (...snip...)
>
> Wow, this seems excellent design and quite widespread in applicability.
Actually the old J2D renderer (which is the basis for Johan's one) was already
doing that, minus the RTree (which I would like to add in the new renderer) and
the lazy loading (the hook was there, but we didn't made the final step). The
cache of decimated geometries was only one step further after the above.
The fact that J2D-renderer was keeping the full (non-decimated) geometries in
memory was one of the main issues reported against it. We didn't implemented the
disposal of oldest geometries like the above C++ implementation, but this is
something that could be added. I agree that it is important.
My measurement at that time suggested that the memory consumed by the cache was
about 2% of the memory consumed by the full geometries. In order to reduce the
memory consumption of the full geometries, J2D renderer had the capability to
compress them in memory.
Martin
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
