[OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?
Laurent Bourgès
bourges.laurent at gmail.com
Thu Feb 26 08:31:03 UTC 2015
Jim,
I made a Path2D patch but I sent the webrev by email.
Did you got it ? Could you review it ?
I got a size limit issue: Your message to 2d-dev awaits moderator approval !
Looking forward having an openjdk id ro push my webrev to cr.openjdk.net !
Regards,
Laurent
Le 25 févr. 2015 02:06, "Jim Graham" <james.graham at oracle.com> a écrit :
> Those changes were exactly what I was referring to. I don't see why we
> shouldn't make trimmed arrays when copying the shape. I'm pretty sure that
> the copy constructors are going to be overwhelmingly used to make a
> protected copy of an existing shape/path2d which is likely meant mostly for
> reading. In particular, in the case of the return value from
> createStrokedShape() I don't think the intention is to create the shape and
> then scribble on it, the intent is to treat the answer as if it were
> immutable - at least the 99.9% case - so I think a perfectly sized shape is
> OK.
>
> Be sure to add a test case that creates an empty Path2D, clones it, copy
> constructs it (to both .Double() and .Float() variants) and then tries to
> add new segments to it - to make sure that the array growth code doesn't
> get ArrayIndexOutOfBounds exceptions due to making assumptions about the
> lengths of the arrays (I eyeballed the makeRoom() code and it looks good,
> but we should test it if we are making arrays that are potentially zero
> length or very tiny)...
>
> ...jim
>
> On 2/24/15 9:58 AM, Laurent Bourgčs wrote:
>
>> Jim,
>>
>> Ah, wait, those constructors do copy the arrays without having to
>>> iterate the segments and grow the arrays, but they don't trim them. I'm
>>> trying to remember if there was a specific reason that we decided not to
>>> trim the arrays in those constructors, but the only "advantage" I can think
>>> of is that the new copy will have the same potential spare room for growth
>>> that the original had. But that is of questionable value so we should
>>> probably just patch the existing "construct from a Shape" constructors to
>>> trim the arrays to the required length instead...
>>>
>>
>> In marlin github, I have the patched Path2D class (not used at runtime):
>>
>> public Float(Shape s, AffineTransform at) {
>> super(); // LBO: invoke empty constructor explicitely !
>> if (s instanceof Path2D) {
>> Path2D p2d = (Path2D) s;
>> setWindingRule(p2d.windingRule);
>> this.numTypes = p2d.numTypes;
>> // LBO: trim arrays:
>> this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>> this.numTypes);
>> // this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>> // p2d.pointTypes.length);
>> this.numCoords = p2d.numCoords;
>> this.floatCoords = p2d.cloneCoordsFloat(at);
>> } else {
>> PathIterator pi = s.getPathIterator(at);
>> setWindingRule(pi.getWindingRule());
>> this.pointTypes = new byte[INIT_SIZE];
>> this.floatCoords = new float[INIT_SIZE * 2];
>> append(pi, false);
>> }
>> }
>>
>> float[] cloneCoordsFloat(AffineTransform at) {
>> float ret[];
>> if (at == null) {
>> // LBO: trim arrays:
>> ret = Arrays.copyOf(floatCoords, numCoords);
>> // ret = Arrays.copyOf(this.floatCoords, this.floatCoords.length);
>> } else {
>> // LBO: trim arrays:
>> ret = new float[numCoords];
>> // ret = new float[floatCoords.length];
>> at.transform(floatCoords, 0, ret, 0, numCoords / 2);
>> }
>> return ret;
>> }
>>
>> What do you think?
>>
>> FYI my use case in createStrokedShape () is to allocate (and reuse) a
>> path2d (4k arrays), fill it and then return a new path whose arrays are
>> trimmed.
>>
>> Laurent
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150226/283f71e8/attachment.html>
More information about the 2d-dev
mailing list