Re: [udig-devel] How to get started with Renderer

[Andrea Aime <aaime@xxxxxxxxxxxxx>]

Vincent Heurteaux ha scritto:
> Andrea,
> GO-1 renderer's goal is to keep and expand J2D performances and 
> functionality and decrease it's complexity with a better architecture.

I really hope so. It has to decrease to a point where other developers
can work on it... the only hope is that it's a rewrite from scratch,
the geometry package was totally unmanageable.

> I've used J2D in the past and I cant say that I'm steel impressed by 
> it's performances and it's capacity to render Windbarbs, dynamic 
> scalebar big raster images etc. ..

It worked beautifully with small data sets, but try to load a 40MB 
shapefile with it, and you started needing a lot of memory. Plus,
it was geared towards interactive display, but for obvious reasons
I'm not interested in that use case now :)

> On the memory consuption side, Martin said it was something not so 
> difficult to fix, so I'm sure it will be manageable in GO-1 renderer.

I hope so. When I read the GO-1 spec it seemed like it was designed
with a full in memory rendering model. I've seen ideas like keeping
in memory the feature ids and reload by id when the cache does not
have any more the feature, this is obviously a performance disaster
with any JDBC datasource. Some kind of tiled design is needed instead
imho, something allowing to gather the elements that are not in
the memory cache in a single call (the network delays will kill
any approach that needs hundreds of separate access).
Plus, caching should be disabled completely in server side apps.
Consider sigma.openplans.org, it's backed by a 20GB postgis database,
there is no way you can do a meaningful caching of it when there
are many concurrent users hitting the server (well, unless you
can give a couple of gigabytes of memory to Geoserver to cache
each user's area of interest).

> I'm just about to find funds to start this work (if everything goes 
> right it will start this summer).
> So wait'n see, I'll keep you in touch (and then I'm sure you will 
> restart your work on the vector stylling ;-) )

I probably won't unless the direction is a radical simplification.
I spent my time once already on it, and luckily not all work was
thrown away because we could reuse the style factory in the
streaming renderer as a performance improvement.
Streaming may be ugly, I agree, but it has the work of various
people over years, and it's stable enough for server side usage.
It'll take lots of work to have a renderer that can do the same,
with the same stability and the million of details that have
been handled over time. To make Geoserver switch or spend time
on it, the advantages must be measurable... nicer code does not
make users any happier ;)

Anyways, when the work starts I'll be following it very closely
(if I'm allowed to, of course), and will toy with it for sure,
share impressions, and so on, it'll be interesting to have
an alternative renderer geared toward desktop apps.
Oh, and I hope this time it'll speak with gt2 datastores
from day 1, instead of requiring further integration work.

Cheers
Andrea