[mapserver-dev] OpenGL Contribution

Tue Dec 16 06:33:46 EST 2008

Attached is an opengl and agg rendering of central Sydney for your enjoyment.

Toby

On Tue, Dec 16, 2008 at 3:03 AM, Dan Little <danlittle at yahoo.com> wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: aggexample.png
Type: image/png
Size: 191856 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20081216/263f2e02/aggexample-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openglexample.png
Type: image/png
Size: 144578 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20081216/263f2e02/openglexample-0001.png