[OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

[Mario Torre]

Hi Laurent,

Let's move the process forward so that you can become an Author, at
that point you'll be able to file bug reports and create webrevs:

http://openjdk.java.net/projects/#project-author

I don't know what was decided regarding the specific project, but
since Jim is lead of the rasteriser project and I believe the general
consensus was for you to start from there, this may be the appropriate
forum, here are some links:

http://openjdk.java.net/census#graphics-rasterizer

http://openjdk.java.net/projects/graphics-rasterizer/

http://mail.openjdk.java.net/mailman/listinfo/graphics-rasterizer-dev

As soon as this process is done, you'll be finally free from a lot of
this crazy overhead :)

@Jim, @Phil is that right?

Cheers,
Mario

2015-02-26 9:31 GMT+01:00 Laurent Bourgès <bourges.laurent at gmail.com>:
> 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
>>>
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/