[mapserver-dev] Rendering a circle with the specified size as the default symbol

[Tamas Szekeres]

Hi Thomas,

Yes it looks like a big effort indeed.
Would it be up to the renderer how their image representation is stored
internally? It seems like the various renderers would use different
parameretes in imageObj, so would it somewhat to be represented as an
untyped parameter (void* for example) or we expect all of those would
represent the images as raw RGBA rasters? Or they should provide their I/O
operations between  their internal representation and the RGBA efficiently?
I guess not all of the renderers would have builtin support for outputting
png or jpeg images therefore this option should be pulled outside of the
scope of the renderers in addition.


Best regards,

Tamas





2009/2/5 thomas bonfort <thomas.bonfort at gmail.com>

> Tamas,
> the effort is deeper than just having a vtable mimicking the
> DrawMarkerSymbol/msDrawMarkerSymbolGD/msDrawMarkerSymbolAGG , as this
> leaves the same amount of code duplication as now.
> the aim will be to define a fine-grained rendering api, in the case of
> your email, down to drawEllipse(width,height,angle,color, ...)
>
> more detail at
> http://trac.osgeo.org/mapserver/wiki/UnifyingTheRenderingInterfaces
> (rather outdated), or the initial implementation in the graphics
> sandbox (
> http://trac.osgeo.org/mapserver/browser/sandbox/graphics/maprendering.c#L435
> )
>
> I'd be very happy to get your feedback on this,
>
> thomas
>
> On Thu, Feb 5, 2009 at 16:09, Tamas Szekeres <szekerest at gmail.com> wrote:
> > Hi Thomas,
> >
> > I'd be curious to know what level of detail will be chosen when selecting
> > the functions to be exposed in the vtable. I thought we'll probably
> select
> > those functions/operatons which are currently provide the branching
> between
> > the renderers.
> > In this particular case we would probably add a DrawMarkerSymbol to
> > represent the renderer specific msDrawMarkerSymbolGD /
> msDrawMarkerSymbolAGG
> > etc, variations.
> > In this regard it remains up to the renderer how the default symbol is
> drawn
> > in effect.
> >
> > Would you describe in more details what you have in your mind about the
> > desired vtable architecture, I'm really interested in.
> >
> > Best regards,
> >
> > Tamas
> >
> >
> >
> >
> > 2009/2/5 thomas bonfort <thomas.bonfort at gmail.com>
> >>
> >> Tamas,
> >> those kind of inconsistencies (as there are quite a few others) will
> >> hopefully be a thing of the past once we switch to the vtable
> >> rendering architecture. I'd favor leaving things as they are for 5.4
> >> and wait for 6.0 for introducing and documenting these changes.
> >>
> >> best regards,
> >> thomas
> >>
> >> On Thu, Feb 5, 2009 at 01:19, Tamas Szekeres <szekerest at gmail.com>
> wrote:
> >> > Folks,
> >> >
> >> > Currently the GD and AGG renderer behaves differently when drawing a
> >> > point
> >> > with no symbol specified. In the code I can see something like for AGG
> >> >
> >> > if(style->symbol == 0) { // simply draw a circle of the specified
> color
> >> >
> >> >
> >> >
> ren->renderEllipse(p->x+ox,p->y+oy,size,size,0,agg_color,agg_ocolor,width);
> >> >         return;
> >> >     }
> >> >
> >> > The corresponding code for GD looks like:
> >> >
> >> > if(style->symbol == 0 && fc >= 0) { /* simply draw a single pixel of
> the
> >> > specified color */
> >> >     gdImageSetPixel(img, (int)(p->x + ox), (int)(p->y + oy), fc);
> >> >     return;
> >> >   }
> >> >
> >> >
> >> > Wouldn't it be reasonable to use the same approach for the different
> >> > renderers? I would prefer the AGG version to be followed.
> >> >
> >> >
> >> > Best regards,
> >> >
> >> > Tamas
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > mapserver-dev mailing list
> >> > mapserver-dev at lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20090206/400e4abf/attachment.html