pre rfc draft on rendering

[thomas bonfort]

On Nov 13, 2007 6:42 PM, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
> Personally I'm all for this type of consolidation. The current setup is indeed hard to deal with.
>
> Some questions/comments:
>
>  - with simple line layers you mention the problem of intersections w/outlines. Do you have an idea beyond the current caching method for producing nice intersections? I can't tell from what is written.

I don't see any other method aside from caching. I think I'll remove
the reference to that outline thing as a whole, as caching aside, I
can't even get the agg renderer to produce satisfactory results on
that end.

>  - with brushed lines, I'm that brushed-based (as opposed to marker-based) lines could be done away with. The really nice AGG example you have isn't really brushing is it? It seems conceptually more like markers with a gap of 0.

with markers you don't get the symbol to bend on curves, and you don't
get the nice joins between each symbol. see
http://www.antigrain.com/articles/line_patterns.gif for an example of
what you can get with that approach. maybe "brushing" isn't the
correct word, but I'd definitely keep this.

>
>  - with labeling, follow: the labelPathObj hools positions and angles already.
>
>  - I notice you're passing most of the components of a styleObj in most cases, why not just a reference to a styleObj?
style->size is scaled by the current scalefactor to obtain the current
symbol size
you can't just update the size value in the actual styleObj, as a
mapscript "msSaveMap" would then save the new size in the mapfile. so
passing along a styleObj would mean creating that styleObj and
populating it with the adjusted values, and on the renderer side
extract the meaningfull values. seems like a step or two more. plus in
that case the renderer function signatures make it pretty clear what
should be done inside them.

>
>  - what if, if any, changes to MapScript to you see? It didn't seem obvious to me that any would be necessary as all this new plumbing could be effectively hidden from the highest level draw calls.

I don't think there would be any changes

>
>  - the GD render does support a simple pixmap cache for vector/ellipse symbols. That should be extended, merged or done away with in favor of a common image cache.

common image cache implies common image format, and that already isn't
the case. I think an eventual cache itself should be renderer-specific
and not taken into account for this. What can be done is that
structures that could require caching have a void* renderer_cache;
that can be populated and used by each renderer if needed. This is how
the agg renderer actually caches pixmap symbols.

>
>  - is this the time to address color? Do we stick with RGB and HEX representations for colors with opacity as a separate keyword?

you know my opinion on that one ;)  I'd like to be able to specify
alpha on a color by color basis as it could avoid going through the
temporary image layered solution we have now. It could also avoid
having to bring the OPACITY keyword into the styleobj.
COLOR r g b #normal full opacity color
COLOR r g b a #color with an explicitely defined alpha value

thanks for the comments,

thomas