[OpenJDK 2D-Dev] RFC: 7019861 + workaround + minor optimization

Jim Graham james.graham at oracle.com
Thu Mar 10 19:23:36 UTC 2011

I think the code is good to go, but could you create an automated test 
case for this?  It should be easy to render a simple shape to a rendered 
image and verify that the last scanline was touched, no?


On 3/10/2011 11:06 AM, Denis Lila wrote:
> Hi Jim.
>> Yes, that was the point of my original question. I was asking how you
>> felt about the dead code, apologies that it took so long to get on the
>> same page. I don't have a strong opinion there, I was just making you
>> aware that there was more dead code. Another option would be to move
>> just the switch statement into a secondary shared function which might
>> be small enough not to trigger that compiler bug.
>> But, I'll leave those decisions up to you. I was just pointing out
>> that
>> you missed some potentially dead code...
> Oh, I see. Well, I wasn't aware of it before you asked, so thanks
> for pointing it out. I guess I'll remove it.
> As for moving the switch in its own function, I think the compiler
> would just inline it and then we'd be in the same spot.
> Shall I push?
> Thank you,
> Denis.
> ----- Original Message -----
>> Hi Denis,
>> ...jim
>> On 3/10/2011 6:38 AM, Denis Lila wrote:
>>>> [Resending due to bounces...]
>>>> On 3/9/2011 5:56 AM, Denis Lila wrote:
>>>>>> lines 1002&  1083 - can breaking points of a cubic generate quad
>>>>>> segments and vice versa?
>>>>> No, the functions that generate the offset curves can only
>>>>> return a line or a curve of the same degree as the curve
>>>>> whose offset they're generating.
>>>> Then why does the code to handle the opposing curve type exist in
>>>> these
>>>> functions?
>>>> ...jim
>>> Because everything was copied from somethingTo, which had to handle
>>> both types of curves, and I applied constant propagation and dead
>>> code elimination very mechanically for fear or breaking something.
>>> Should I remove the cases that never execute?
>>> Regards,
>>> Denis.

More information about the 2d-dev mailing list