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
