[mapserver-dev] OpenGL Contribution

[toby.rahilly at gmail.com]

The use case that led us to an OpenGL renderer was on demand high quality  
map-rendering instead of using pre-rendered tiles. Benefits of this are:

* Lower maintenance costs as any changes to the data are immediately  
represented in the rendered maps
* More dynamic maps, as changes to the map files are immediately  
represented in rendered maps which can lead to more interesting interactive  
uses. For instance you could dynamically highlight features of interest, or  
each user could have their own custom map file preferences.
* And if we had decided to pre-render the tiles, reducing rendering time  
from weeks to days or even hours.

Unfortunately I do now have access to the more detailed debug timings at  
the moment, but in general a central city map rendered in AGG took 2  
Seconds, rendered in OpenGL took ~150ms with pre-rendered textures on a  
7800GT Nvidia video card. Biggest improvements were in layers with repeated  
complicated symbols suchs as train tracks and also label rendering time was  
hugely improved. OpenGL was still significantly faster than AGG in detailed  
layers that do not make use as textures, such as cadastre and road layers.  
I am not sure of a use case where the textures would need to be frequently  
re-rendered. I will post more detailed timings as soon as I have them  
available, but it might not be until next week.

* Pre-rendering is performed per layer, so each layer has the symbols  
rendered according to its own settings.
* Font rendering is done via a third party library that performs its own  
caching. Characters are rendered and cached on first use, and each font  
size is rendered and cached separately.
* The cost of implementing non-win32 opengl support is hard to judge before  
begining. The code that needs to be ported is the OpenGL context creation  
code, which is about 100 lines of code. But by no means does the entire  
renderer need to be recoded.

Changing to dynamically rendering and caching textures is very possible, in  
fact that was our original implementation. It's worth noting that textures  
are not stored as bitmaps, but instead as an internal OpenGL representation  
and is stored not in main memory, but in video memory.

We want to support the entire MapServer spec. There is still holes in are  
implementation as we prioritised what we used.

Working on the module rendering branch sounds like a good idea, as it will  
force us to refactor the rendering module to suit MapServer.

Regards,
Toby

On Dec 15, 2008 7:25am, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> 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
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20081215/d4f82081/attachment.html