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

[Jim Graham]

Hi Laurent,

ShapeSpanIterator.c was written many years ago, I'm refining the 
techniques now that I look at them again and how they are used here.

BTW, my recent proposal of 32.32 is nothing new - that's essentially 
what the SSI technique is - it just isn't described that way. 
Technically it is 32.31 with a lost bit so that we only maintain 31 bits 
and use the sign bit for carry in doing separate int operations.

Also, if you want to pack/unpack longs, then you could just put the 
x1_fixed and slope_fixed into the edge array.  All the int operations 
are really doing is "long arithmetic using ints with a manual carry".

I'm not sure about the general math in all of the rest of the renderer 
and how it might be affected by 32.32, but that should be a separate 
effort.  The advantage of 32.32 for the crossings analysis is that the 
operations are a simple iterative add, but in the rest of the code you 
have a lot of other operations going on.  Also, 32.32 requires more data 
to be operated on than a single precision float.

I have not seen the Graphics Gem you are referring to so I have no 
experience with applying it.

I'd test both the float version of my suggestion and the double version 
to make sure that we know how much the doubles will cost us.  Hopefully 
it would be in the noise.

I didn't develop the inc/dec algorithms, they were added by Denis I 
believe, but they were based on some standard DDA curve techniques that 
you could probably find on Google...

			...jim

On 7/30/15 1:07 AM, Laurent Bourgès wrote:
> Jim,
>
> I advocate I simply made a port of your FP approach in
> ShapeSpanIterator.c without really understanding well the equations to
> adjust the edge to pixel centers.
> If there is a precision issue, it is also impacting the
> ShapeSpanIterator.c !
>
> Your recent proposal is very interesting (32.32 FP) as it could be
> generalized to lineTo / curveTo in order to make all curve breaking
> computations in 32.32 (long) maths ?
>
> When I compared marlin vs ductus quality, small difference remain on
> lines and I suspect it is related to the pen fitting. Do you know how to
> apply the polygonal pen approach ( mentioned in graphics gem I ) ?
> It seems a good method to ensure consistent line width based on
> adjusting coordinates on the raster grid (24.8 FP).
>
> I will make corrections soon and try your new approach asap (double + 32.32)
>
> Moreover, could you explain me the dec/inc algo for quad/cubic curves ?
> I found error= | dd (x,y) | / 8.
>
> However the norm is not equal to max [ abs (ddx), abs (ddy) ]...
> I now use squared norm check = ddx * ddx + ddy * ddy.
>
> Thanks for all your advices,
> Laurent
>