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

[Laurent Bourgès]

Jim,

let's go back to concrete code:

2015-04-04 0:25 GMT+02:00 Jim Graham <james.graham at oracle.com>:

> The patch as it is will make things much better, but it may be worth
> "doing it right" as long as we are revisiting this algorithm and write it
> to deal better with the OOME/integer overflow cases.
>

My patch is very simple and a lot better for huge paths.
It is not perfect as it does not handle integer overflow (impossible case
for me) nor OOME.

How could I handle OOME first ? any advice ?

I could try allocating a smaller array in case of OOME ? any example in JDK
?


> I looked at the ArrayList code and found a bit of voodoo there in the
> overflow code which troubled me as a potential maintainer.  It's one thing
> to write clever code, it's another thing to write clever code that others
> can come along and maintain without having to fill a white board with
> input/output ranges and 2's complement rules.  It's not like this code is
> going to be in an inner loop somewhere - the time for a couple of
> conditional checks and min/maxes will be vastly swallowed by the costs of
> allocation and copying data so it would be better to just write
> straightforward code whose overflow considerations are documented for
> future maintainers.  (Having said that I probably wrote some pretty
> obtusely clever code in the Rectangle class myself... D'oh!)  My general
> goal is to include comments with the incoming assumptions and then document
> how I've ruled out cases and narrowed ranges with small single-line
> comments as the calculations and decisions are made...
>

Please give me hints, so I could improve the proposed webrev.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20150408/02f5e0e5/attachment.html>