[OpenJDK 2D-Dev] Various fixes to pisces stroke widening code

[Jim Graham]

Hi Denis,

float operations are pretty fast and they are usually done in a separate 
part of the processor so the compiler can schedule a lot of bookkeeping 
instructions to run in parallel with waiting for the results of the FP 
instruction.  In the end, they often end up being "free" if there are 
enough bookkeeping instructions (branches, fetching data, etc.) in 
amongst the data.

Given how many alternate instructions you are pointing out for the fixed 
point code it would be very likely that this would be a "win".

The main reason that Pisces is implemented heavily in fixed point is 
that it was originally written for the mobile platform where there are 
no FP instructions.  We don't have to worry about that on the desktop 
(any more).

I strongly support you converting things to fp if you want to do it...

			...jim

On 7/12/2010 8:05 AM, Denis Lila wrote:
> Hello.
>
> Is it ok if I do this? I already started working on it on Friday.
> I think I should be done by tomorrow.
>
> But yes, I agree that we should convert to floating point. As for
> performance, there's also the fact that right now we're trading
> one double multiplication for 2 casts to long, 1 long multiplication,
> 1 bit shift of a long, and 1 cast back to an int. I don't know much
> about how these are done in hardware, but it doesn't seem like they'd
> be faster than the double multiplication.
>
> As for large coordinates, there's a bug report about it (one not
> reported by me :) ) here: https://bugzilla.redhat.com/show_bug.cgi?id=597227
> I submitted a matching bug report on bugs.sun.com (ID 6967436), but I
> can't find it when I search for it.
>
> Denis.
>
> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
>
>> Sigh...
>>
>> Pisces could really stand to upgrade to floats/doubles everywhere, for
>>
>> several reasons:
>>
>> - FPU ops are likely as fast if not faster on modern hardware due to
>> parallel execution of FP instructions alongside regular instructions.
>>
>> - Don't have to worry about getting coordinates larger than 32K (I
>> don't
>> think this is well tested, but I imagine that Pisces will not deal
>> with
>> it very gracefully).
>>
>> - Lots of code is greatly simplified not having to deal with the
>> semantics of how to do fixed point multiplies, divides, and
>> conversions.
>>
>> I meant to do this during the original integration, but I wanted to
>> get
>> the task done as quickly as possible so that we could have an open
>> source alternative to the closed Ductus code so I left that task for a
>>
>> later update.  But, now that a lot of work is being done on the code
>> to
>> fix it up, it might be better to do the float conversion now so that
>> the
>> maintenance is easier and before we end up creating a lot of new fixed
>>
>> point code.
>>
>> My plate is full right now, but hopefully I can interest someone else
>> in
>> doing a cleanup cycle?  (Donning my Tom Sawyer hat... ;-)
>>
>> 			...jim