Jim & phil, The initial objective of my patch concerns the grow algorithm to use 1/8th of the array size instead of the fixed EXPAND_MAX (=500) !
For huge paths, it avoids a lot of growing passes and is a lot faster (see Path2DGrow test: 2s vs 56s). However, it wastes more memory (overflow or OOME can occur) so arrays should be trimmed manually or automatically when calling some methods like getPathIterator (). It is not possible to infer what is the Path2D usage pattern... and when a growable array should be resized down (too much waste threshold ?) I think the bug you created does not mention the problem on the grow algorithm at all. That fix could be backported to 1.8 except new trimToSize () methods. Le 21 avr. 2015 00:11, "Jim Graham" <james.gra...@oracle.com> a écrit : > > To answer my own question - since we already have a changeset with just the new trim-on-copy stuff that is backwards compatible and since this change only adds the new trim method and some overflow protection, we can just go with the previous fix if we decide to backport things. The added value of the new overflow protection is not enough to further split this particular change down... I disagree: the new grow algorithm is a lot better for huge paths and is an important performance fix that should be backported to 1.8 too. Should I update the bug description or create a new one like 'Path2d needRoom very slow for huge paths' ? Laurent
