[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] shapefile renderer planning
|
Jody Garnett ha scritto:
On 26/09/2009, at 6:08 PM, andrea antonello wrote:
let's talk, would will we need to do to keep it? I think we really
should. Might be something for the code sprint.?
Well what we need to do is sign up as maintainer; right now shapefile
renderer is not even hooked up in uDig since we have been short of
people working on core.
I think the best thing we could do is help put together a patch for
streaming renderer to give it the "bitmap" look aside optimisation that
shapefile renderer enjoys. However we probably need to talk to Andrea
and ask what a good course of action is since he is more closely
involved at the moment.
Yup, that would be best, if adding that patch makes streaming renderer
even "only" twice as low as the shapefile renderer in that specific
case (assuming I'm still missing something about what makes the
shapefile one tick so fast) I would say it would be more than enough to
drop the shapefile one.
Anyways, here is the original message I've sent to gt2-devel and
gs-devel.
Cheers
Andrea
-------------------------------------------------------------------
During the last couple of months I've been working in the
background to make the streaming renderer + shapefile
datastore work at a similar level of performance as the shapefile renderer.
The reason for that is simple, to avoid the double maintenance
the shapefile renderer code imposes on the rendering subsystem.
With the patches I've committed today (after testing them in
my checkout for a few weeks, the biggest one for longer)
the streaming renderer should have become more or less
as fast as the shapefile one in most common cases, but one,
and faster in another.
The slower case is when the shapefile to be painted is
disproportionately bigger than the area to be painted.
The shapefile renderer here uses a trick, it keeps a binary
map of the pixels where anything has already been drawn,
and any feature smaller than a pixel gets compared to it,
and not drawn at all if the pixel has been touched once
already.
This gives it a 10x speedup compared to the streaming
renderer, but at the price of breaking solid any thematic
map: if you think about a map in which there are a number
of tiny geometries to be colored according to their attributes
and, say, all the red ones are read fist, you'll just get
a red map, because the geometries with other colors just
won't be painted over the red ones.
Basically this way the shapefile renderer gives the user
a fast overview of where things are, but breaks the actual
thematic distribution.
The case in which the streaming renderer is faster instead
is mapping with multiple feature type styles to get a layering
effect: the streaming renderer will allocate multiple back buffers
and do a single scan of the data source, whilst the shapefile
renderer will scan the data source one time per feature type style
(so the streaming renderer speedup is proportional to the number
of feature type styles involved).
I would like to just drop the usage of the shapefile renderer
and move it to unsupported land before we go RC.
Opinions?
Cheers
Andrea
PS: btw, the bitmap trick of the shapefile renderer could be
implemented in the streaming renderer too, it's just more
difficult in that streaming has to deal with features
with multiple geometries.
Anyone wants that badly?
-------------------------------------------------------------
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
