[OpenJDK 2D-Dev] Path2d needRoom very slow for huge paths

Laurent Bourgès bourges.laurent at gmail.com
Thu Apr 2 20:35:16 UTC 2015


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.race at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150402/af626f16/attachment.html>


More information about the 2d-dev mailing list