Jim, 2016-11-10 0:39 GMT+01:00 Jim Graham <james.gra...@oracle.com>:
> Going forward perhaps we should refer to the version of Marlin in Java2D > as Marlin2D? > > Then Marlin is your original plug-in version that is still being worked on. > Marlin2D is what you integrated into OpenJDK/Java2D. > MarlinFX is what you are planning for FX. > I agree your naming convention. > > That's just for conversational purposes, I'm not proposing that we > formalize those into formal project names, but this will keep discussions > smaller? > > On 11/2/16 2:54 PM, Laurent Bourgès wrote: > >> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >> will synchronize both branches to provide soon MarlinFX9 patches closer to >> OpenJDK9's Marlin renderer if we are going to work on its integration. >> > > If I read this correctly, you have outstanding changes you've made to > Marlin that you plan to propose for Marlin2D, but they haven't been > proposed yet? > Exactly but I told you several times (in this thread): - I started optimizing tile filling in Marlin 0.7.5 (asymetric tiles W != H) and it is 10% faster for almost empty (0x00) / full tiles (0xFF) but also it speeds up larger tiles (128 x 32 ...) than usual (32 x 32) - I switched to Marlin-FX and found out that OpenPisces (Dasher / Stroker / Renderer cubic decimation thresholds) were changed compared to Pisces2D so I ported all these changes to Marlin-FX (first) - Very minor fixes in Renderer loop: block flag bug + fast exit loop on the right side - Increased array size for edge / crossings / polystack (as in 0.7.3) If you prefer, I can first upgrade Marlin2D then propose a new webrev for MarlinFX for its integration. Anyway Marlin changes are very small compared to Marlin2D or MarlinFX and are located in principal classes. > > And you based MarlinFX on the newer version of Marlin with those > outstanding changes? > Yes but MarlinFX do not have MarlinCache nor MarlinTileGenerator where are located changes for optimizing tile filling. To sum up, MarlinFX has small changes from Marlin to make it compliant with OpenPisces. > > Is your plan to propose a patch for Marlin2D soon? > Yes to make Marlin2D up-to-date and behave like OpenPisces / MarlinFX. > > For now I'd like to keep the 2 versions of Marlin in the JDK in sync other > than differences required for Java2D's rendering pipelines vs. the FX > ones. That will simplify at least the intial proposal to integrate this if > we can say it is "99% the same as the one in Java2D other than differences > required by the pipelines" which should quiet any fears that might get in > the way. > > Did I read that correctly? Does that sound reasonable? > MarlinFX is now ready and up-to-date to behave like OpenPisces. Finally I submitted yesterday a new webrev on JBS and expected it would have started a new review thread (as this one is too long !) Please have a look to my comment: https://bugs.openjdk.java.net/browse/JDK-8169270 " Please review the marlin-FX webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/ Reviewers: flar This webrev consist in Prism classes (ShapeUtil, SWContext) using the new Marlin renderer ported to JavaFX. The PrismSettings class has been modified to have the new prism.marlinrasterizer flag (disabled by default). Marlin-FX is slightly different than Marlin OpenJDK9 to: - use javafx classes instead of java2d classes - fix Dasher / Stroker as done in OpenPisces - support both AA and nonAA Renderer (see MarlinRenderer interface) - fix Renderer cubic decimation thresholds to match OpenPisces nonAA quality - the new MarlinAlphaConsumer supports optimized alpha copies (only valuable ranges) and the block flag optimized fills for the MarlinRasterizer only (not SWContext) Note: The SWContext.DirectRTPiscesMarlinAlphaConsumer relies on PiscesRenderer.emitAndClearAlphaRow() that is not optimal with the Marlin approach as it expects a complete row [x0, x1] although Marlin gives the span [xmin, xmax] where coverage != 0. The prism-native-sw (c code) could be improved to accept an extra offset to skip useless pixels [x0, xmin] and improve the blending performance. Will upgrade later OpenJDK9's Marlin renderer or if you prefer, I can do it first. " Best regards, Laurent
