I can understand to promote the 99% use case (small path) but the performance penalty is too important to me for large paths....
Let's have jim's point of view as he knows the complete story... Laurent Le 2 avr. 2015 19:33, "Phil Race" <philip.r...@oracle.com> a écrit : > I should have paid more attention to the context. > So it appears that 500 has been the value since 1998 and > it was made that under this bugid when the code was all > still in GeneralPath.java > > https://bugs.openjdk.java.net/browse/JDK-4134316 > > prior to that fix it was even smaller > > < static final int INIT_SIZE = 10; > < static final int EXPAND_SIZE = 10; > --- > > static final int INIT_SIZE = 20; > > static final int EXPAND_MAX = 500; > > Looks like something we should get Jim's view on since although > a lot has changed since 1998 there may be some negative > consequences he is aware of. > > -phil. > > On 04/02/2015 10:15 AM, Laurent Bourgčs wrote: > >> >> Phil, >> >> Just a short comment: >> >> > pisces was originally written for the "ME" environment so I suspect that >> > it was very conservative in allocating new heap space. That clearly >> does not >> > matter so much on desktop so the proportional approach rather than >> > the fixed size approach seems better. 1/8th seems conservative and >> > since the results look good so I don't object. >> >> I think Path2D is part of the java2d api and seems not related to pisces ? >> >> > I think a new bug id would be required as this is another thing that >> > might be backported to pisces in 8u60. >> >> Agreed. >> >> Laurent >> >> >
