Fwd: Re: Marlin-Renderer and JavaFX

Laurent Bourgès bourges.laurent at gmail.com
Thu Nov 10 13:29:16 UTC 2016


2016-11-10 0:39 GMT+01:00 Jim Graham <james.graham at 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:

Please review the marlin-FX webrev:
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
- 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

Best regards,

More information about the openjfx-dev mailing list