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

[Laurent Bourgès]

Jim,

>> 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.

I like the pipeline uses float or double for accuracy (many affine
transforms) but in the rasterizer (Renderer) deals with pixels and
typically 8x8 subpixels. That's why I would like using integer maths (fixed
point) in the Renderer for performance even in the curve breaking ...
without sacrifying the quality.

>>>> - 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.

It seems these values are 32 (quad) and 8 (curve) so it seems related to
the scaling factor = 8. It would be great to express this dependency in the
constants.

>
>>>> - 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).

I understand it is not enough in the scanline processing but such 24.8
(1/256th) coordinates are more precise than 28.4 (1/8th) so it sounds
possible to me to use them as inputs in addLine and curveBreak to compute
the edge error, bumpx, bumperr as you did in  32.32 format for good
accuracy. I want to make the curve culling as fast as possible and avoid
floating-point maths in Renderer (and the slow ceil/floor calls).
Of course it means its PathConsumer methods must convert float inputs to
precise enough integer coords...

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20150714/f273f357/attachment.html>