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.gra...@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
