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

[Laurent Bourgès]

Dear all,

I am pleased to see this discussion so intense with many different point of
views.

I am still looking for a concrete plan on how to improve openjdk's
rasterizer:
- I started by improving Pisces code (better memory management)
- then I made more refactoring and it became an alternative renderer as
marlin (still derived from pisces + same GPL license)

I asked several times how to contribute back marlin to openjdk since may
2014... as pisces patches ? or as an alternative renderer ?

I never got a clear answer but we discussed that topic a lot at FOSDEM and
now in this thread.

If you grant me rights to push code into the graphics rasterizer project, I
would push the marlin source code to let you study it and test it with all
necessary test suites.

As I said so many times, you can already get the marlin 0.4.5 release (src
+ bin on my github) and tell the jvm to use it:
java -Xbootclasspath/a:[path]/marlin-X.Y.jar
-Dsun.java2d.renderer=org.marlin.pisces.PiscesRenderingEngine ...

>> The impact of including it in OpenJDK seems to be fairly small: it is an
>> implementation of an existing SPI, and there's no need to make it the
>> *default*  right away. It can be included and live side-by-side and
>> require some runtime flag to get it enabled. And when enough testing has
>> been done, eventually switched to default.

Yes that's exactly how marlin is used at runtime. Moreover, it can use
several System properties to tune it (tile & subpixel sizes...)

> Note that the "SPI" is there not any more since its now a Class.forName
> but a while ago I assured Laurent that this would still work for him - at
> least until jigsaw arrives which was also noted at the time.

I tested latest marlin release with openjdk 8 and 9 and it works well.

> Is this really a side-by-side living with each other proposal ?

Please tell me what to do...

I think if some of you could spend some time trying marlin on any test
platform... it would be very great to have evaluations & feedback.

> A previous exchange characterised it as "merging" which is a wholly
> more risky proposition:
http://mail.openjdk.java.net/pipermail/2d-dev/2014-May/004609.html

> Can it be structured as "sun.java2d.marlin.MarlinRenderingEngine"
> and leave existing pisces well alone for now ?

Yes, it is possible to refactor it; marlin uses the org.marlin package but
still the PiscesRenderingEngine class.

> I don't think I've ever seen a webrev against openjdk (ready to be
corrected if wrong
> but I can't find one in my email) and definitely not one that looked like

In mid 2013, I submitted early patches against pisces; then it evolved in
the marlin github and then asked how to proceed.

> Does it alter any behaviours or touch any code that does not involve
> the marlin code path ?

I modified the the sun.java2d.pipe.AAShapePipe classes (tile cache) and
added the awt.geom.FastPath2d to trim and clone paths efficiently
(createStrokedShape).
These changes can be considered minor and trivial (may be optional).

> If there was initially zero impact on any production code I can see that
being
> more acceptable but I don't understand why its a problem to demonstrate
> this by putting it in an OpenJDK Project sandbox and thereby be something
> we can build so that JCK and SQE could look at it first - pisces is after
all
> part of the RI used to pass TCK, and sometimes there's a performance
> vs spec. adherence trade off in what we do.

I am a bit lost...
please clone the git repository and push it in any openjdk project you find
appropriate and run your build & test suites.

If you all agree, I could do that work but I am only an openjdk contributor
with no rights !

Of course, tell me if you have any issue; I will be glad to help as much as
possible.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150220/88d7f034/attachment.html>