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

[Laurent Bourgès]

Jim,

>
> Interesting numbers.  It was hard to read the formatting on the diff
> below, but I got the gist of what was happening.
>

Sorry for the bad formatting but you had a chance to understand what I did:
great !


>
> Were the ceil(coord) measurements taken with the new ceil_int() code? For
> this case it might make sense to call ceil_int() directly since we can be
> pretty sure that the fp coordinate values are all in the integer range
> (since these are drawable-relative numbers).
>

It uses FloatMath.ceil() that internally use the ceil_int() implementation
for performance.
I agree it should use directly the ceil_int() to be more explicit.


> Another technique to try would be to use longs which would involve a
> 64-bit shift to get the integer part, but there is already a 32-bit shift
> to add the error overflow anyway.
>

I may try as a last chance if removing Unsafe usage is not faster.
I really like this approach as it will remove a lot of code = Unsafe usage
+ OffHeapEdgeArray + dispose / cleaner thread.

Moreover, hotspot may optimize more such normal array accesses than Unsafe
calls (intrinsics); however, it may also introduce array bound checks ...

To be continued ... but anyway, I really like the fixed-point solution:
fast and more accurate.

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