[OpenJDK Rasterizer] Marlin renderer contribution for review

[Laurent Bourgès]

Jim,

>> - improve coordinate rounding ie ceil(x - 0.5) or better ?
>> Maybe ceil/floor(float) intrinsics could help but let's discuss that in
>> the core-libs mailing list...
>> I have found another trick about float rounding:
>> http://stereopsis.com/sree/fpu2006.html
>> Or you may have other ideas as you did in your JavaFX renderer ?
>
>
> We might want to consider fixed point in the inner loops and then we can
bypass the issue entirely.  It would also mean that we'd only need one kind
of array for storing segments.  The main advantage to using FP is if you
have a lot of FP math and a lot of integer stuff, then the FP math can
sometimes hide in the gaps between the integer and logic instructions since
they can execute in parallel.  But, if you run across an expensive FP
operation then fixed point might be faster anyway.

There are 2 issues:
- dasher, stroker, transformer and curve culling provide coordinates as
float values that finally call Renderer.addLine (floats) which converts it
to the subpixel grid
=> rounding to subpixel centers is necessary
=> fast floor / ceil functions are useful and also in endRendering() to
adjust the shape area to subpixel clip bounds.

It is then possible to convert coordinates to fixed point 24.8 format =>
edges as integer values (like agg).

2. Scanline processing
Currently crossings as integer subpixel x coord are incrementally computed
from previous crossing + slope (float) and casted to integer => rounding
issue at x position.

In this hot loop, using fixed point maths could help (= DDA) but its error
should be properly propagated.

It may be faster if dda is properly and efficiently implemented.

Do you know some good books or readings on this topic ?

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