Alternate rendering engines to GD...

[Tamas Szekeres]

Frank Warmerdam wrote:
> Yes, if we want to make output drivers pluggable, I think we might do it
> by extending the outputFormatObj to include function pointers for things
> like DrawLayer().   

Frank,

IMO the interface should be more fine grained than simply expecting the
provider to draw the layer for its own. Otherwise for a vector layer the
provider should deal with the data providers to obtain the shapes for the
layer. Mapserver should provide the isolation between the data providers and
the output providers

It would be more convenient for the renderers to deal with rendering the
drawing primitives (point, line, polygon, image, text) or at most drawing at
the shape level (including the mapserver specific symbology).
  

> Note, unless we have folks deploying MapServer that want to have their own
> local renderers not kept in the core source code there isn't much need
> to make this formally plugable.  The current switch statement approach
with
> #ifdef's depending on what render libraries are available is sufficient.

It is worth considering to allow both the static and the dynamic linkage of
the output providers (it applies to the pluggable and the built-in layer
data providers as well).

Best Regards,

Tamas


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.7.0/345 - Release Date: 2006.05.22.