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

[Phil Race]

Hi,

On 2/20/2015 10:06 AM, Laurent Bourgès wrote:
>
> 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 ?
>

As I've asked for a long time, a webrev you create against openJDK is 
what I'd like to see.
I can't assess what a delta it would be against pisces without that.
But I would suppose its reached the point where its such a large delta that
side-by-side alternate renderer is the way to go for now.



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

Since no one from the JDK graphics team that is responsible for this area
attends FOSDEM I can't say what happened there and whether the people
you talked to are informed in this matter.


> 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.
>

That is what Dalibor and others recommended and have been working to 
help you with.

> 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).
>

FastPath2D would be public API. Perhaps that should be a separate discussion

> > 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.
>

Lets be clear. We'd love this stuff if its as good as we are told but we do
not have the time to be more proactive on this.

Also we cannot legally "grab" this stuff   anyway no matter how much you
say its OK. You need to contribute it into OpenJDK by creating the webrev
and submitting it.

So
1. Work with Dalibor to get the rasteriser project have a forest at 
http://hg.openjdk.java.net/
2. Integrate your marlin code there in  way that co-exists with pisces 
and does not
introduce any new APIs
3. We will then be able to more easily create builds to ask SQE run 
tests against it
and so forth.
4. It then becomes much easier to see the path into putting it into the 
main repo.


-phil.

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

You can be a graphics rasteriser project committer quite easily ..
To be an openjdk committer requires a lot more time and effort and is
again why we keep saying use the graphics rasteriser project.

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