[OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer

Laurent Bourgès bourges.laurent at gmail.com
Fri Mar 11 17:06:23 UTC 2016


Jim,

Thanks for your comments.

I agree the filtering algorithm is not very obvious with too many flags
(skip, pathClosed, subpathStarted) that represent lots of conditionnal
statements and possibly corner cases. If I have time, I may try simplify it
but in a second step.

I will a new tests for createStrokedShape () and also draw(shape) with
non-uniform transformation.

Le 11 mars 2016 03:02, "Jim Graham" <james.graham at oracle.com> a écrit :
>
> Actually, there is one functional difference between this implementation
and the Ductus pipeline...
>
> The similar method in the Ductus pipeline is operating entirely on device
space coordinates after all transformation (which is why it can have
normalization built-in).
>
> The method you modified is sometimes called on transformed device space
coordinates, but in the case of a draw operation it can be called on user
space coordinates if the transform is non-uniform.

Good catch.

> Since this change will solve the issue for fills and uniform-scaled
draws(), it handles the 90% case, but if you use a non-uniform scale of
more than 2x, then it will still allow overflow in the final rendered path
if a coordinate is near UPPER_BND...

I wonder if such case is not only theorethical, as a typical canvas is
integer based ie MAX_INTEGER << MAX_FLOAT.

By the way I started refactoring MRE.strokeTo () to get rid of outat ie I
propose to remove the optimisation for non-uniform at as I prefer filtering
transformed coordinates once even if it requires invDelta / Delta transform
stages in the pipeline.
I hope it will not impact too much the performance but it simplifies
notably the logic and the code.
Do you have an alternative solution (simple) ?

Besides, we should also check early if the transformation matrix contains
NaN or Infinity values avoiding the path iteration. I advocate it is an
extreme case.

Ps: I will send another patch during the week end.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160311/75c86d6a/attachment.html>


More information about the 2d-dev mailing list