Grid of thin lines in polygon symbol fills

[havatv]

In maprendering.c, when rendering polygon fills using symbols, 1 is added to the symbol size in both the x and the y direction for scaled symbols:

652	            if(s.scale != 1) {
653	               pw = MS_NINT(symbol->sizex * s.scale + s.gap)+1;
654	               ph = MS_NINT(symbol->sizey * s.scale + s.gap)+1;
655	            } else {
656	               pw = symbol->sizex + s.gap;
657	               ph = symbol->sizey + s.gap;
658	            }

This produced a grid of thin lines of "background" colour in the polygon fill at the symbol boundaries (both for GD and AGG).

I am not that familiar with the code, but since the GD renderer does not do anti-aliasing, eliminating the one unit addition should make it easier to get good polygon fill rendering with GD.

I have tried to remove the one unit addition, and if I am careful with the SIZE, the result looks better (both for GD and AGG). It does not seem to produce worse looking results for non-optimal SIZEs. But it might of course have other unwanted side effect.

[havatv]

Some more on this one.

I have done the simple fix that I suggested. Here is the diff (6.0.0 branch, but probably the same in trunk):

svn diff mapserver/maprendering.c
Index: mapserver/maprendering.c
===================================================================
--- mapserver/maprendering.c	(revisjon 11726)
+++ mapserver/maprendering.c	(arbeidskopi)
@@ -488,8 +488,8 @@
                   int pw,ph;
                   imageObj* tile=NULL;
                   if(s.scale != 1) {
-                     pw = MS_NINT(symbol->sizex * s.scale)+1;
-                     ph = MS_NINT(symbol->sizey * s.scale)+1;
+                     pw = MS_NINT(symbol->sizex * s.scale);
+                     ph = MS_NINT(symbol->sizey * s.scale);
                   } else {
                      pw = symbol->sizex;
                      ph = symbol->sizey;
@@ -650,8 +650,8 @@
             }
 
             if(s.scale != 1) {
-               pw = MS_NINT(symbol->sizex * s.scale + s.gap)+1;
-               ph = MS_NINT(symbol->sizey * s.scale + s.gap)+1;
+               pw = MS_NINT(symbol->sizex * s.scale + s.gap);
+               ph = MS_NINT(symbol->sizey * s.scale + s.gap);
             } else {
                pw = symbol->sizex + s.gap;
                ph = symbol->sizey + s.gap;

I attach images that show the change in behaviour.

[havatv]

patched version

[havatv]

gif

[havatv]

gif patched version

[havatv]

patched version (ellipse)

[havatv]

gif (ellipse)

[havatv]

gif patched versoin (ellipse)

[havatv]

The attachments show the effects of the patch for vector symbol fill and ellipse symbol fill for gif (GD) and png (AGG).

[havatv]

It would have been very nice to get some feedback on this one.

Could somebody explain why the extra pixel is added to the size in the current code, and why it would be a problem to remove it.

If there is no problem, I hope that the patch can be applied, as current behaviour is a showstopper for many "advanced" area fill symbols of type vector.

[tbonfort]

fixed in r12707.

the reason this pixel was added was to account for the antialiasing of vectors which bleeds out of the strict bounding box given by the symbol's size. The workaround in that case will be to add a sufficient GAP to account for this.

[havatv]

The trunk symbol construction document has been updated (r12724).