[mapserver-dev] RFC 54: MapServer Rendering API

Thomas Bonfort thomas.bonfort at camptocamp.com
Fri May 15 03:24:28 EDT 2009


On Mon, May 11, 2009 at 15:20, Toby Rahilly <toby.rahilly at gmail.com> wrote:
> Sorry for the late response on this.
>
> I have been taking a look at the RFC and also updating OpenGL to the
> latest graphics branch code base.
>
> Overall the new graphics API is quite nice, and will make it a lot
> easier to develop plugin renderers in the future.
>
> Some thoughts:
>
> * The RFC mentions using tiles for line patterns but I don't see it in
> the code.
The whole "tile" concept is in standby, as I'm not yet quite sure how
to treat it. Treating a tile as a plain imageObj is nice as it
simplifies the api (you call the same functions for creating a tile
than for rendering in a normal image), but I'm not sure that that fits
well with the opengl model, and also poses problems when dealing with
caches (notably the freetype font cache).

> It is important for OpenGL to be able to cache line
> patterns.
By pattern, do you mean "tile" or are you referring to something else?

> shapeObj does have a rendering cache, but will shapeObj
> instances always be rendered with the same strokeStyles?
The cache in the shapeobj should only be used to store a renderer
specific cache of the *geometry*, and not anything related to styling
imho.


>
> * I don't understand the raster rendering options. The comment in the
> code snippet for the rasterBufferObj says the pixel buffer is
> "private", however the RFC goes onto say that the raster layer code
> will "directly sets individual pixels where needed". OpenGL can return
> a COPY of its internal buffer, but requires the use of OpenGL
> functions to set individual pixel values.

it's private in the sense that only the renderer knows how to directly
access the pixel buffer. Outside code should only access it through
the r,g,b,a pointers, using pixel_step and row_step to iterate through
pixels. This allows a renderer to export a handle to its internal
pixel representation so that the raster handling code can directly set
individual pixels (that is, outside of the rendering api).

For the opengl case, I think we have no other way of treating raster
layers than returning a copy of its internal buffer, unless opengl
specific code is added in mapserver's raster handling, right? I don't
think Frank will be very keen on that.


>
> * With the new save functions I've separated OpenGL from any GD code
> by exporting a rasterBufferObj (with a COPY of the internal buffer).
>
> * The responsibility of handling line ends in labels has moved back
> into the renderers? It seems a lot of the Glyph placement
> responsibility is still handled by the renderers, is it possible to
> move any of it out? Especially as renderers provide the
> "getTruetypeTextBBox" method.

yes, the previous implementation was a quick hack to get things
working. It might be possible to move line wrapping out of the
renderers, but that would result in multiple calls to
getTruetypeTextBBox - not a big deal but that would require a bit of
refactoring.
I would also like to stop passing a char* to the renderers for the
actual text, but instead use an int* that directly gives the unicode
points of the glyphs, so the renderers don't have to cope with utf8
decoding.

>
> * The RFC states for marker symbol tiles "It probably isn’t a good
> idea to use a tile cache if the symbols have to follow line
> orientation, as rotating a cached tile will produce poor results.".
> OpenGL uses tiles for the marker symbols and does rotate them with
> little quality degradation. OpenGL drivers are heavily optimised in
> this area (anisotropy filtering).

The renderers could have a configuration flag that states that doesn't
need to cache rotated symbols, and that it will cope with rotating the
received tile.

>
> An option may be to render the tiles at set amount of different angles
> (e.g. every 45 degrees), and then pick the tile closet to the required
> angle.

I'd leave this out of the rendering api, and let individual renderers
implement that if they need.

>
> * The Tile cache code in maprenderering.c is still quite incomplete
> and makes it difficult to test the OpenGL renderer.

see above... I was waiting on your input on how to treat tiles. I
think we will have to go down the more complicated route of having
renderers create tiles as void* instead of imageObjs, as the latter
case is too constraining:

Tile as ImageObj:
  + simple api (the same for creating tiles and normal images)
   - less flexible
   - can be problematic when dealing with caches

Tile as void*
   - very flexible (the renderer can store anything it wants)
   + coding a renderer is more complex, as there are two different
apis (rendering on a normal image, and rendering to a cache)

Maybe a mix of both solutions could be nice, by having the renderer
provide configuration flags saying which symbols can be treated as
imageObjs, and which ones should be seen as void*


>
> * "startNewLayer" and "closeNewLayer" are not required by OpenGL if
> the opacity is separately applied to all rendered styles in that
> layer.

you mean opacity at the style level?
we still need to support opacity on layers as a whole, where a new
layer is created and merged as a whole onto the resulting image.

Best regards,

Thomas


More information about the mapserver-dev mailing list