[OpenJDK Rasterizer] RFR: Marlin renderer #3

[Laurent Bourgès]

Jim,

Sorry I did not merge the 2 mails!

>> Maybe DDA or floor (val) or ceil (val + 0.5) should be used instead in
>> both places ?
>
>
> I'm not sure how DDA impacts this since it is simply a formula for
computing the exact location where the curve crosses the scanline. Either
way we need to somehow determine how to interpret that crossing and that's
where the ceil()/floor()/cast decision comes in.

I meant dda with fixed point maths (integer) to get rid of floating-point
maths in endRendering () => no cast, ceil, floor anymore.
But of course addLine () must still round float coords to integer and deal
with dx/dy and error...
Do you have experienced such approach in the past ?

Do you know how to do it well ?

> In other parts of the system we skip all segments that have a NaN
anywhere in them.
>
> sun.dc.DuctusRenderingEngine.feedConsumer has tests to eliminate NaN
segments (this class is in the public repos even though it is feeding the
Ductus library).

Ok I will try porting the same algo but MAX_BND should be MAX_FLOAT /
sub_pixels = 8 .

>> 2/ Determine edgeBucket used range: correct too.
>>
>> - Floor: it is used by NormalizingPathIterator to compute x/ adjust
>> values = 0.5 - fractional_part (coord).
>> Here the possible values may be in the full float domain !
>>
>> Probably I should use a correct Floor impl as before or propose a new
>> method to compute the fractional part directly.
>> Fract = coord - floor (coord) = coord % 1f
>
>
> What do you mean by a correct Floor impl?

My previous impl supporting the complete float input range ie not limited
to integer range.

> I'd have to see how the fract method would be used there to see if it
makes sense.  One thing I noticed when I read through that code is that we
duplicate some calculations.  In particular, we have:
>
> coord = coords[N];
> adjust = <round calc> - coord;
> ... then after the if statement:
> coords[N] += adjust;
>
> This is equivalent to:
>
> coord = coords[N];
> adjust = <round> - coord;
> val = coords[N];  // This is the same as coord, right?
> coords[N] = val + adjust;  // This is the same as <round>, right?
>
> We should just do it all together as in:
>
> coord = coords[N];
> val = <round>;
> coords[N] = val;
> adjust = val - coord;
>
> It saves a memory load and having to undo a subtract with an add.

The fract method itself may also avoid the substraction ...

>
>> Any idea?
>> Again how to deal with NaN / Inf values in this case ?
>
>
> This is interesting because if we ever encounter a NaN then the adjust
parameters will tend to carry it forward in all of the calculations and so
the rest of the path could become all NaN values.  Hopefully the code I
pointed out above can provide an idea of how to deal with this.
NormalizingPathIterator could serve both as a normalizer and a NaN
rejecter.  We'd need some form of NaN rejection for the case where
STROKE_NORMALIZE is turned off, though.

Seems definitely a good idea, but it also looks like a sort of a clipping
algo ... (again).

PS: Could you give me an example when the rendering clip boundaries may be
negative ?

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