On Sat, 2 Apr 2022 08:29:43 GMT, Jay Bhaskar <jbhas...@openjdk.org> wrote:
> Issue: Floating point overflow , when making end point for line drawing as
> FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0);
> Solution: traverse widths to calculate end point and increment start point.
I instrumented the code, and discovered that in the failing case, the list of
`widths` is empty. I see that other implementations of GraphicsContext have a
check for this at the beginning of the method, and do an early return in that
case. That seems a good idea regardless. So I recommend adding this around line
345:
if (widths.size() == 0)
return;
That alone is sufficient to fix this bug.
As for the change to loop over the widths array, I'm not sure about that part.
I see code in some of the ports that treat the widths array as pairs of start /
end values, but that doesn't match what I see in a simple strike-through test
case where there is only a single width value.
For the case of a simple underline (with or without dashing), the widths array
is of length 2 with the first value being 0.0, which tends to support the
definition used by the other ports. This will need more analysis.
So I think the simplest (and safest) fix is to just add the check for size ==
0, but leave the drawing part of the code unchanged, and file a follow-up bug
to investigate.
-------------
PR: https://git.openjdk.java.net/jfx/pull/765
