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
