[OpenJDK Rasterizer] Fwd: Re: Fwd: RFR: Marlin renderer #3

[Jim Graham]

> I quickly tried but sorry it provides no gains: Float.isNaN() is just
> implemented as (a != a) so it is faster with only 1 condition (a != a)
> than 2 (intval == 0 && (a != a)).

Another way to make NaN tests fall out naturally from your code is to 
make sure that they are always in the "numeric test failed" branch. 
Currently you have them in the "numeric test succeeded branch.  What if 
you inverted the test?  As in:

if (a > intpart
     && CHECK_OVERFLOW && !overflow)
{
     return intpart +/- 1;
}
return intpart;

In this case NaN causes the first test to fail and you jump straight to 
the "return intpart" code without having to explicitly test for it...?

Basically we tend to have tests of the form "if (number is bad) return 
failure" and NaN isn't caught by that.  If we instead use "if (number is 
good) { do things }" then NaN values will fail to make it into the code 
block.  Usually when these are at the top of a function we'd rather test 
for bad values and return instead to avoid extra indenting, but then an 
alternate way is to use:

	if (number is good) {
	    [*]
         } else {
	    return failure;
         }

[*] no code there, we only really needed the else, or:

	if (!(number is good)) {
	    return failure;
	}

But, if the code block is small and has no further indentation needs, 
then generally the following is naturally NaN-resistant:

	if (numbers are good) {
	    // do all the calcs...
	}

			...jim