pre rfc draft on rendering

[Tamas Szekeres]

> >
> > 2. It would be useful to separate the functions implemented by
> > renderers (in vtable) from the  renderer independent functions. Would
> > a renderer be able to override the drawLayer for example?
>
> can you give an example of when this would be usefull ?
>

It's just for making the things obvious. We should decide which
functions will make up the vtable and implemented by the renderers.


> >
> >
> > 3. How would you change the imageObj for holding the renderer
> > dependent image representation. Would it be a 'void * imagedata' or
> > something like that?
>
> very probably, that seems to be the only dirty but c-compatible way of
> accepting anything. If you have other ideas I'd be glad to have them.
>

That's kinda way have already been used in mapserver like 'void
*layerinfo' holds the driver dependent layer information. I'm not
aware of any other right now.

> >
> > 4. How the renderers would be plugged in?
> that's too much for my limited experience in the subject. For the time
> being the aim is only to have the renderers present a common
> interface.
> >
>

I think the current approach for the providers is pretty usable here
as well. Every renderer would implement the initializeRenderer style
functions and would responsible to fill the vtable pointers with the
appropriate values. I guess it could be initialized upon parsing or
changing the OUTPUTFORMAT DRIVER parameter. We could as well
introduce:

OUTPUTFORMAT
    NAME mapserverwingdi
    DRIVER PLUGIN
END

would load the mapserverwingdi.dll which implement a windows GDI
renderer for mapserver :-D

BTW outputFormatObj is also a good candidate  for holding the renderer
vtable if we would keep from introducing new structures.


Best regards,

Tamas