[mapguide-internals] RE: Trying to improve AGG

[Walt Welton-Lair]

I've attached the modified source to the RFC - https://trac.osgeo.org/mapguide/attachment/wiki/MapGuideRfc52/AGGUpdateSource.zip.  It's based off of trunk revision 3818.

Walt

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Sunday, April 12, 2009 12:59 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: Trying to improve AGG

That was a pretty comprehensive set of tests and, as long as the performance impact isn't too great, I think that enabling both of those features would be reasonable.

Is there some way that you can provide modified DLLs for us to test our own datasets with or, failing that, a patch that I can apply to my local copy then pass along to others?

Jason

________________________________________
From: Walt Welton-Lair
Sent: Friday, April 10, 2009 12:26 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Trying to improve AGG

Hi All,

I've attached a zip file to RFC 52 (https://trac.osgeo.org/mapguide/wiki/MapGuideRfc52) which includes some images showing what I think is an improvement in AGG rendering quality.  Basically I wanted to understand why AGG renders some lines thicker than expected.  This was reported on Zac's website: http://zacster.blogspot.com/2008/02/mapguide-20-agg-versus-gd-renderers.html.

Here's a summary of what I was experimenting with:

1/ I tested using two data sets: one containing relative sparse data and the other dense data.  The sparse data set was rendered using a hatch fill based on the new stylization, while the dense data set was rendered using just an outline.

2/ AGG does sub-pixel rendering.  While this lets it do nice anti-aliasing, it does result in some oddities like vertical / horizontal lines being thicker than expected (see the feedback on Zac's website).  I found that by clamping the point coordinates passed to AGG to integer values these oddities went away, but at the cost of slight pixelation.

3/ We currently do not generalize data when rendering with AGG or GD (except in a few special cases like when there are dashed lines).  By "generalize" I mean reducing the amount of data we actually render, based on the current zoom level.  For example, if I have an island with a border represented by 10000 vertices, and I'm zoomed out so the island only spans a few pixels, then we can remove some of these points and render the reduced set to get nearly the same visual effect.  In my tests I experimented with enabling generalization of data that was being rendered as polylines (polyline features, or the edges for polygon features).

4/ I did not do any performance testing.  For now I just wanted to focus on quality.  I expect that enabling point clamping by itself will have no noticeable impact on performance - it's just rounding values.  The performance impact of generalization would need to be investigated.


For those interested in this, please have a look at the images.  The zip file contains a number of folders, each with two images to compare.  Each folder also contains a text file describing what's being compared.

Please let me know what you think.  As far as options go: here's what I see:
*       do nothing: the change is not acceptable
*       enable just the point clamping changes
*       enabled both the point clamping changes and generalization (pending performance investigation)

Thanks,
Walt

 W       E         @__   __o
   A   T   R   @___    _ \<,_
     L           @_   (*)/ (*)


_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals