[mapserver-dev] OpenGL Contribution

[Dan Little]

I was going to say, that I am absolutely ecstatic to see this implemented.  With OpenGL (and an optimized library for a video card) Mapserver can access the high performance rendering of the latest GPU's across a range of video cards.  This is a significant step towards improving rendering performance and the ability to push mapserver's capbilities into a HPC environment.

Now, if someone (*cough* Toby) would be so kind as to post a GD vs. AGG vs. OpenGL rendering sample ... I think it would give some of us something to salivate over.




________________________________
From: "toby.rahilly at gmail.com" <toby.rahilly at gmail.com>
To: mapserver-dev at lists.osgeo.org
Sent: Sunday, December 14, 2008 8:59:09 PM
Subject: Re: Re: Re: [mapserver-dev] OpenGL Contribution

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/a647f95d/attachment-0001.html