Unifying The Rendering Interfaces

page to keep track of ideas and notes concerning "pluggable" renderers, and their interface with the main mapserver program

Desired Functionality

Line Layers

• simple: straightforward case, need to pass vertexes, width, color, and optionally caps and joins
  • dashed
  • outlined: the renderer can provide a method to draw a solid line with a one pixel outline in a single step
• brushed: used essentially with a pixmap symbol as in
  
  • pixmap
  • vector,truetype : investigate if this should be supported. very probably have to be transformed to a pixmap before being used internally by the renderer.
• markers : different strategies can be used here
  • naive: mapserver computes marker positions and orientations, and for each computed point calls the renderer's appropriate marker function
  • optimisation: mapserver passes a list of points and orientations to the renderer, and all the markers are rendered in one pass
  • optional: the renderer provides a method for automatically calculating marker locations (see ​this thread for a discussion of this feature with AGG)

Point Layers

should be pretty straightforward. must probably expose a way for the renderer to cache an internal representation of the symbol if needed.

• vector
• pixmap
• truetype
• ellipse

Polygon and Circle Layers

• simple: straightforward, provide vertexes and color
  • outlined: same question as line shapes, provide a way to draw an outlined shape in a single step
• hatched
• tiled
  • vector
  • ellipse
  • pixmap
  • truetype

Labelling

• font caching: gd has a global font cache, accessed through a mutex. AGG currently attaches the font cache to its imageObj.
• encoding: gd tries to automatically detect encoding. options can either be to pass on the encoding to the renderer, or always convert to utf8 for example.
• simple: straighforward once caching has been solved/decided
• follow: font rendering function is called once per character. could be optimized by passing the whole string and a list of positions/angles.
• bounding box : used by the labelcache to determine which labels can/will be drawn. With gd this is easy as the font cache is global. For other renderers, the font cache could be tied to the fontset object.

Raster Layers

A possible solution to avoid function call overhead while allowing the raster functions to set single pixel values could be for the renderers to expose an inlined setPixel (and getPixel?) function, probably without any bounds checking for performance. for example

inline void setPixelAGG(imageObj *im, int x, int y, int r, int g, int b, int a) {
 im->buffer[x][y]=AGGPixelMacro(r,g,b,a);
}

and then use a vtable approach to connect that to a generic setPixel function.

I/O and Pixel Formats

All I/O is currently done with gd (or not: geotiff,etc)

pixmap input

• have gd load pixmaps, and let the renderer convert and cache on first access

or

• let the renderer provide a pixmap loading function

image output

• the renderer converts its internal image representation to a gdimage and let gd do the saving

or

• have the renderer provide saving functions directly (i.e. call directly libpng/libjpeg/...)