Fwd: Re: Marlin-Renderer and JavaFX

[Jim Graham]

Hi Laurent,

Great job on creating a very obvious minimal impact!  That should help streamline it through the approval process.

Is MarlinProperties.isEnabled still used?  (Searching patch file - no, I don't think so)

Kevin and I had a long back and forth over the packaging of the Reentrant files and came up with 
"com.sun.util.reentrant" as we'd like to avoid "com.sun" as a terminal package.  We should eventually move a few other 
common utilities into that new tree as well, but we can start with these classes.

I still want to take a pass through the changes to the Marlin files themselves, but above is my review of the glue code 
and with that Kevin can pursue the internal processes.

Before I pursue too far on reading the Marlin source changes, I'd like to hear back about how this version of Marlin(FX) 
differs from the OpenJDK version of Marlin(2D) - were they based on different versions of your Marlin project?  Also, 
you mentioned waiting for the jigsaw build patch integration.  I'm guessing you meant the build changes that happened 
yesterday, so we can proceed now?

With respect to the changes to the native part of the SW pipeline that would trim the rendering - please continue to 
investigate them, but we should pursue those as a separate bug fix so as not to complicate this particular change.  It 
sounds like you've adapted the new code in the SWContext wrapper class to not require that native change yet, so let's 
go with that for the first phase...

				...jim

On 11/7/16 2:55 PM, Laurent Bourgès wrote:
> Jim,
>
> Here is the new patch:
> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/
>
> Changes:
> - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner)
> - modified PrismSettings as recommended and renamed all Marlin properties
> to use the prefix 'prism.marlin'
> - SWContext: added Marlin SW support: I had to tweak the processed range[x;
> pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does not handle
> properly the bbox so it processes many extra pixels on the left side (empty
> coverage) = to be discussed as it can be fixed in the native prism-sw code
> ... See my comment in the code:
>
> +            @Override+            public void
> setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+
>                                                final int pix_from,
> final int pix_to)+            {+                // use x instead of
> pix_from as it cause artefacts:+                // note: it would be
> more efficient to skip all those empty pixels [x to pix_from[+
>        // but the native implementation must be fixed too.+//
>       pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from,
> pix_to, rowNum);+                pr.emitAndClearAlphaRow(alpha_map,
> alphaDeltas, pix_y, x, pix_to, rowNum);
>
> I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143
> (xpatch.args) with Ensemble8 + DemoFX.
>
> Maybe it is time to start the review for the FX enhancement ?
> https://bugs.openjdk.java.net/browse/JDK-8169270
>
> Cheers,
> Laurent
>
>
> 2016-11-04 19:55 GMT+01:00 Jim Graham <james.graham at oracle.com>:
>
>> On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
>>
>>> For SWContext, I figured out that only openpisces.* classes were used
>>> directly via imports (hardcoded) so I left it unchanged. So you propose
>>> to generalize use of marlin or native pisces ?
>>>
>>
>> I didn't notice that, I was just searching on the use of
>> "doNativePisces".  We can look at that separately, and Kevin would know how
>> frequently we end up in the SW pipeline these days...