[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] ShapefileRenderer and SLDStyleFactory
|
Andrea Antonello - I located where the problem is.
Andrea Aime - it seams that there is more performance to tease out of
LiteralExpression and the use of Converters
andrea antonello wrote:
Just load ANY shapefile and it will be wrong. bc_borders for example
will load as black lines. Th eglyph shows that it should be green
lines (in my case now), but the lines are black.
Okay I have reproduced the problem ... moving through shapefile renderer
I noticed that (at least for the sample uDig data set bc_borders) the
poor renderer has to skip over a lot of records (logging all the way). I
wonder if we can clean up our data set for increased initial speed?
Moving on to SLDStyleFactory (the bit of code that takes an
LineSymbolizer and converts it to stuff we can use for painting...).
Turns out the problem is actually here...I can watch a good Style go in
and Black (the fallback value) gets used instead.
I can watch LiteralExpression.evaulate call:
public Object evaluate(Object feature, Class context) {
return Converters.convert(literal, context);
}
When the literal is "#189E77" (ie a String) a converter is supposed to
step in and make that into a Color for us... previously the SLDParser
would try and convert data into a Color up front when parsing; and in
several cases the renderer assumed the color would be a literal!
Now that we are actually treating this thing as a real expression we are
finding a few bugs like this one.
Andrea Aime: I noticed LiteralExpression.evaulate( feature ) is
performing similar guesswork to what the SLDParse used to do; storing
the result as a "parsedValue". Can I make use of your parsedValue field
to store the last result from evaulate( feature, Class ) ?
I also wonder if a few Converters (like the ColorConverter) could keep a
WeakHashMap of previously converted values - the performance gain could
be felt across all Expression implementations then.
Ok, I do not think for our purposes the theme will be mandatory, but
perhaps than we should hide it until it isn't here again.
I do not mind either way; it is an alpha release so having functionality
from a previous release that needs fixing may entice volunteers? As an
example our printing code was not working very well; leaving it in the
application brought in a contract to fix it.
Jody
