[mapserver-dev] RFC 54: MapServer Rendering API

[Toby Rahilly]

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. It is important for OpenGL to be able to cache line
patterns. shapeObj does have a rendering cache, but will shapeObj
instances always be rendered with the same strokeStyles?

* 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.

* 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.

* 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).

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.

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

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

Cheers,
Toby


On Tue, Apr 21, 2009 at 3:46 AM, Thomas Bonfort
<thomas.bonfort at camptocamp.com> wrote:
> On Mon, Apr 20, 2009 at 6:21 PM, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
>
>> Do you have a feel for how the raster code would have to be changed? Seems like it
>> would have to be able to write to a GD buffer and rasterBufferObj. I guess that's why you
>> reference time and/or $'s for that change.
>
> Yes, the gd specific code would have to be kept. The raster code would
> have to be modified to write to an arbitrary buffer with the obly
> knowledge of the byte ordering, and pixel and row stride.
>
>
>>>>  - how should renderer options be encoded in an output format (presumably
>>> not
>>>> as a format option, perhaps a new renderer option (hash?))
>>> formatoptions aren't ideal, but these options would mostly be specific
>>> to each renderer. What are you thinking of when talking of a hash ?
>>
>> I was thinking of this, in mapfile syntax:
>>
>> OUTPUTFORMAT
>>  ...
>>  RENDEREROPTIONS
>>    'key' 'value'
>>    ...
>>  END
>> END
>
> Yes, that sounds reasonable. The current formatoptions could
> internally be in there to (and decide if we keep backwards
> compatibility on the formatoption keyword in the mapfile)
>
>>
>>>>  -  what will the make-up of the more specific rendering objects such as
>>> line styles
>>>> look like?
>>> Not sure I understand your question here. What do you mean by "make-up" ?
>>
>> The RFC references objects like 'strokeStyleObj' and 'symbolStyleObj', what will
>> those look like?
>
> strokestyleobj contains color, width, pattern and caps/joins.
> symbolstyleobj  contains scale and orientation, colors and outlinewidth.
> labelstyleobj  contains the full path to the font, size, orientation,
> color and outlinecolor (shadowcolor could be included too, or factored
> out a level above)
>
>>
>>>>  - reference maps are still necessary but I think we could attack them by  turning a
>>>> request for one into an internal mapfile and handing it off to the renderer.
>>>
>>> The scale, legend and overview will be needing some major refactoring
>>> anyways, but this will be probably be done in a second phase once the
>>> rest of the api has stabilized.
>>
>> The legend and scalebar will be hard since they have significant layout tasks
>> associated with them.
> It won't be trivial, but nothing too difficult I think.
>
>
> thomas
>
> --
> www.camptocamp.com
> +33 4 79 26 57 97
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>