MS_NINT assembly macro is broken

[john.cole@…]

Here a layer I'm trying to render:

LAYER
		DATA "Church"
		GROUP Landmarks
		TYPE POINT
		MAXSCALE 24000
		LABELMAXSCALE 10000
		STATUS DEFAULT
		LABELITEM "Name_R"
		CLASS
			NAME 'Church'
			COLOR 0 0 0
			SYMBOL 'square'
			SIZE 5
			STYLE
				SYMBOL "square" 
				SIZE 3
				COLOR 255 255 255
			END 
			STYLE
				SYMBOL "square" 
				SIZE 1
				COLOR 0 0 0
			END
			LABEL
				COLOR 0 0 102
				TYPE TRUETYPE
				FONT arial
				SIZE 8
				ANTIALIAS TRUE
				POSITION CR
				FORCE TRUE
			END		
		END
	END

in 4.4 it appears like:

---------
|       | 
| ----- | 
| | - | | 
| ----- | 
|       | 
---------


In 4.6 and 4.8 the squares are not centered and appear to have random centers.

---------
|-----  | 
||-  |  | 
|-----  | 
|       | 
|       | 
---------

or

---------
|       | 
|       | 
|-----  | 
||-  |  | 
|-----  | 
---------

[john.cole@…]

This is how the symbol appears in 4.4

[john.cole@…]

This is how it appears mangled in 4.6 and 4.8

[sdlime]

That's not good is it. Working on it...

Steve

[sdlime]

Hmmmm... It works perfectly for me (CVS HEAD and 4.8.2). You didn't send me the
square symbol so I used the test mapfile below. What does your symbol definition
for a square look like? (I'll post my test image as an attachment)

Steve

MAP
  NAME 'bug 1716'
  EXTENT 0 0 500 500
  SIZE 250 250

  SYMBOL
    NAME 'square'
    TYPE VECTOR
    FILLED TRUE
    POINTS 0 0 0 1 1 1 1 0 0 0 END
  END

  LAYER
    TYPE POINT
    STATUS DEFAULT
    FEATURE
      POINTS 10 10 40 20 300 300 400 10 10 400 END
    END
    CLASS
      NAME 'Church'
      COLOR 0 0 0
      SYMBOL 'square'
      SIZE 7
      STYLE
        SYMBOL "square"
        SIZE 5
        COLOR 255 255 255
      END
      STYLE
        SYMBOL "square"
        SIZE 3
        COLOR 0 0 0
      END
    END
  END
END

[sdlime]

Test output from Steve's test mapfile...

[john.cole@…]

I'm trying this with 4.9 in FWtools on Fedora Core 5 and I'm seeing the same
problem as 4.6 and 4.8 on windows.

[john.cole@…]

Steve,
  Here is my square symbol:

Symbol
	Name 'square'
	Type VECTOR
	Filled TRUE
	Points
		0 1
		0 0
		1 0
		1 1
		0 1
	END
END

I think this came from the sample symbol file on the mapserver site.

[john.cole@…]

Made with 4.9 from FWtools on linux.

[sdlime]

I tested one more time here and all is well. I'll try today on my work box 
(Linux)...

Steve 

[sdlime]

I can confirm the problem on my Linux machine at work. Why it would be OS 
dependent is not apparent. Argh....

Could be purely GD I suppose. What version are you running? Any patches applied?

Steve

[john.cole@…]

Steve,
  On the linux box, I'm using FWTools-1.0.0b2 version of mapsever (from last
week).  According to YUM, it has 2.0.33-6.2 of GD installed, but I think
mapserver is set up to use the one in the FWTools-1.0.0b2 tools directory.

On Windows I'm using MS4W 1.16 with no other GD installed (though  PHP might
have loaded a copy, I'm not sure).  With MS4W, I can use the mapserv_44.exe and
the problem goes away, but using mapserver_46.exe or mapserver_48.exe I see the
same problem as on the linux box.

[sdlime]

I have tracked this down to strange rounding behavior with MS_NINT on linux. At
some point a developer changed the code to use a system rounding routine and
that routine appears to have a flaw. It does not round number.5 consistently.
For example, 241.5 rounds to 242, but 242.5 also rounds to 242 (instead of 243).
That causes interesting effects like this. MacOS uses the original macro which
works correctly. Targeting 4.10...

Steve

[dmorissette]

CVS logs suggest that Frank is the one who added those macros, so he would be
the one who would know best what to do about them:

----------------------------
revision 1.400
date: 2005/03/24 22:25:32;  author: frank;  state: Exp;  lines: +140 -103
Implement assembly for MS_NINT on win32 and linux/i86.
----------------------------

[sdlime]

We've been chatting about this off list. The assembly macro seems to be the 
problem. That needs to be fixed. May need Norman's help...

Steve

[fwarmerdam]

I'll take it. 

[fwarmerdam]

I have determined:

fistp (asm), and lrint() are defined by IEEE to round 0.5 values toward the
nearest even integer value!  Apparently this is some sort of "feature" to 
prevent systematic bias up or down. 

The computation of the offset location for the symbols in mapgd.c is
particularly sensitive to this behavior since symbols are usually an odd 
size (ie. 7x7) and so if the placement location is on an integral location,
there is always a 0.5 to round.  

My solution: 
 1) I modified map.h to always publish the "safe" version of MS_NINT as
    MS_NINT_GENERIC, and I modified the mapgd.c symbol offset computation to 
    use this.  This solves this particular bug, and I think the one place 
    most likely to be sensitive to this 0.5 rounding.
 2) Add a --disable-fast-nint configure option so that folks can use more
    the more reliable rounding for everything if they want. 

I'm hesitant to use the flow MS_NINT for everything by default since in some
heavy rendering cases it makes as much as a 5% differernce in speed.  On
the other hand, we might want to make fast-nint off by default in the future
if it gives us other problems. 

Changes committed in cvs head in time for 4.10 beta2 release.

[fwarmerdam]

also added an msautotest/misc/bug1716.map test for this issue.

[sdlime]

Problem is knowing where rounding to the nearest even integer might have a 
pronounced affect. May be worth an inventory at a later date. One area might be 
the conversion to image coordinates, I'm thinking in particular when using 
percentages with inline features. For example, now it is possible to define a 
border (e.g. rect) that will match the output image size regardless of what 
that might be. Since the conversion from percentage to pixels probably uses the 
rounding code I could see where this off-by-one issue could cause unexpected 
problems depending on the even/odd nature of the image dimensions. The result 
would be a missing border edge or a gap between the border edge and the edge of 
the image. 

Steve