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

[Jim Graham]

On 7/14/15 5:28 AM, Laurent Bourgès wrote:
> Jim,
>
>>> Few ideas to discuss:
>>> 1/ I wonder now if the gridding = ceil (x/y - 0.5) should be done
>>> differently: why not apply the offset to - 0.5 to points before curve
>>> decimation or adding lines: it may saves a lot of substractions:
>>> AddLine (x1,y1,x2,y2) implies 4 substractions whereas lineTo (x2,y2)
>>> only needs to adjust the last point.
>>> Idem for curve decimation, shifting points may help.
>>
>>
>> I like this idea - you can bake the translation into the transform that is applied prior to the rasterizer so there is no added work being done.
>
> Will try asap, maybe tonight. I mean I will shift coordinates early in
> tosubpixx() and tosubpixy () by -0.5f.

Good point.  It could probably still be done by the same transform, but 
it makes sense (and improves code independence) to keep it isolated in 
the Renderer class instead.

>>> - do you know if the breakCurveAndAddLines (quad or cubic) really takes
>>> into account the supersampling scale to generate only segments needed
>>> and no more ?
>>
>> I don't remember.  I'd have to read the code and figure it out.
>
> Thanks, it seems there are some thresholds BND... but I am unable to
> find out what it is related to ?

I'd have to research that as well.  I briefly understood them when I 
reviewed the code and I was able to fine-tune them once when we had 
failures in the FX version, but they are essentially a variant of 
"epsilon" but related to the adaptive subdivision algorithm so I mostly 
just treated them as tuning parameters - an accuracy vs. time tradeoff.

>>> - I use fixed-point (32.32 + error) as you did but it is maybe too
>>> precise: the slope, bumpx and error could be determined from integer
>>> coordinates for starting / ending points = ceil (x1 - 0.5), ceil (y -
>>> 0.5) directly
>>
>>
>> I don't understand what you are getting at here...?
>
> I wonder if Renderer class could use 24.8 fixed point coordinates early
> in tosubpixx() and tosubpixy () to have 1/256 precision in lineTo,
> curveTo, quadTo before addLine and curve culling to get rid of
> floating-point maths early.

The problem with 1/256 precision is that you accumulate 1/256 error with 
every step.  With 8 levels of sub-pixel precision that means you can 
accumulate a full sampling error every 32 pixels.  For nearly vertical 
lines where they tend to cross a whole column of samples at once that 
means you are off by 8 coverage values every 32 pixels (scaled by the 
256/64 coverage scale to a difference of 32 in the alpha value).

				...jim