[mapserver-dev] OpenGL Contribution

[thomas bonfort]

huh, sorry I hadn't seen the draft rfc attached to the original post,
so reading it has answered my questions related to font and raster
stuff.

A few other questions come to mind:
* about precaching symbology, fonts, etc: I think many mapfiles
include a system-wide font and symbology file, only a subset of which
is used in each mapfile. Prerendering everything when only a subset
will be used seems like a waste of cpu cycles. For the AGG renderer in
the pixmap symbol case, the pixmap image buffer is converted to an agg
compatible format on first access only, and is later accessible for
subsequent calls. I think something similar should be done for
anything that needs this kind of transformation, eg by supplying a
void* to each structure so that a renderer can store a private
representation if needed.
* you talk about prerendering fonts and cache them as bitmaps. How
does this fit with varying font sizes (as the size can be read from an
attribute, and/or be different depending on the layer)?
* what's the cost of implementing non-win32 opengl support?

best regards,
thomas

On Sun, Dec 14, 2008 at 20:44, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> hi,
> I think this is a very interesting subject, at the minimum from an
> implementation point of view. I second Paul's concerns and am eager to
> read your response on his questions.
>
> We had a discussion a few months ago on tilted output for
> navigation-like image output. An opengl implementation might be simple
> way of achieving this, by pushing a projective-matrix in the pipeline.
>
> What level of compatibility are you expecting to obtain with respect
> to the current mapfile symbology? notably for raster support and
> truetype font handling? To put this in other words, do you plan to
> implement a fully functional renderer that can be fully switched to
> from the GD et al. ones, or only a subset to accelerate line and
> polygon drawings.
>
> As for the svn stuff, I'm planning on creating a branch in the coming
> weeks to support "pluggable" renderers, which I hope will cut off much
> of the code duplication that lies in our renderer implementations. It
> might be a good idea to work on this common branch rather than you
> having to duplicate this stuff once more.
>
> regards,
> thomas
>