pisces, produceFillAlphas

Jim Graham james.graham at oracle.com
Thu Oct 15 22:18:07 UTC 2015

Chien pointed out a system property that is currently disabling the 
scrolling optimization.  For its implementation look at 
CacheFilter.java, in particular the invalidateByTranslation() method and 
all that it kicks off.

Another thing to look at is that we added alpha batching to the code 
which should be batching all of the output of the produceAlphas calls 
into a texture and then drawing all of the quads together - provided 
that they are all being filled with simple colors (they can have alpha, 
but they can't be gradients, etc.).  This should be managed by the 
BaseContext.updateMaskTexture() method which controls the single batch 

Again, are there similar number of invocations of the glDrawElements on 
the 2 platforms?


On 10/15/15 12:30 PM, Johan Vos wrote:
> Thanks Jim.
> I tried with different optimization flags, but it doesn't make a big
> difference. Tracing it down to system calls, somehow the gl
> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
> per invocation. The number of invocations is comparable between iOS and
> Android.
> If you can give me a direction on where to search for the disabled
> scrolling optimization, I'll try to re-enable that and see how it
> improves performance. It might be a huge and quick win...
> Thanks again,
> - Johan
> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>> wrote:
>     Perhaps optimization flags with the native compiler?  Also, was it
>     called a similar number of times on both?
>     Ideally we'd just be using copyArea for the scrolling, but at one
>     point we disabled the scrolling optimizations on retina MBP because
>     they didn't work with a scale factor and I don't think we reenabled
>     them yet.  That would kill scrolling performance on mobile as a
>     result of having to rerender the scene on each scroll regardless of
>     how long produceAlphas takes...
>                              ...jim
>     On 10/15/15 4:27 AM, Johan Vos wrote:
>         After spending lots of time optimizing JavaFX on iOS, I am now
>         at the point
>         where scrolling is 10 times faster on iOS than on Android.
>         The scrolling in the iOS version of the Gluon JavaOne mobile
>         schedule
>         builder is pretty good imho. On Android, it is much slower. I
>         profiled and
>         compared both, and it turns out that on Android, we spend lots
>         of time in
>         the native implementation of
>         NativePiscesRasterizer.produceFillAlphas
>         (implemented in native-prism/NativePiscesRasterizer.c)
>         On average, calling this native function on an iPhone 6 takes
>         40,000ns
>         whereas on a Nexus 6, this takes about 800,000ns.
>         If anyone has a suggestion on how to improve or avoid this, I'm
>         all ears.
>         Thanks,
>         - Johan

More information about the openjfx-dev mailing list