[OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?
bourges.laurent at gmail.com
Fri Feb 20 18:06:21 UTC 2015
I am pleased to see this discussion so intense with many different point of
I am still looking for a concrete plan on how to improve openjdk's
- 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:
>> 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:
> 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
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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the 2d-dev