pisces, produceFillAlphas

[Johan Vos]

It's been a while, but I did more investigations in the performance of
JavaFX on mobile.
The good news: I had a look at a number of individual applications, and
managed to increase fps for all of them with a factor between 2 and 5 (e.g.
15 fps -> 60 fps)
The bad news: it is hard to do this in a generic way.

There are many tips described on this wiki page:
https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks
One of the important things is this:
To cache, or not to cache? That is the question!

   - Every time the thing being cached changes, it is very expensive to
   redraw it.
   - But reusing the baked image a zillion times is faster than redrawing!


That turns out to be very true. By caching Nodes that hardly change between
pulses, performance can improve a lot. However, caching the wrong Nodes
decreases performance. In the end, a smart algorithm that determines which
Nodes are candidates for being cached would help with this (sort of
"hotspot" improvements).

For now, I think the JavaFX libraries can address this. Nodes that are used
for a ToolBar are for example good candidates for being cached.

- Johan

2015-11-17 20:59 GMT+01:00 Johan Vos <johan.vos at gluonhq.com>:

> This is an ongoing effort.
> Performance is #1 on my list, but it is also a very complex issue. I will
> inform this list on relevant progress I make. It is impossible to say how
> much time I need for this, but in the end, I'll get there (and only then I
> will be able to tell how much time it took).
>
> - Johan
>
> On Tue, Nov 17, 2015 at 11:56 AM, Felix Bembrick <felix.bembrick at gmail.com
> >
> wrote:
>
> > Hi Johan,
> >
> > Have you been able to find enough time to be able to answer this
> question?
> > In my present situation, clarity on these issues is extremely important
> to
> > me and I would guess to many others as well.
> >
> > Thanks,
> >
> > Felix
> >
> > > On 18 Oct 2015, at 19:01, Felix Bembrick <felix.bembrick at gmail.com>
> > wrote:
> > >
> > > Hi Johan,
> > >
> > > If you have been getting acceptable but not stunning performance on
> > Android and all this time hardware acceleration was not being utilised
> then
> > it sounds like there is some serious room for some dramatic performance
> > increases.
> > >
> > > Not being that familiar with the finer points of how JavaFX is
> > implemented on Android, just how much work is involved in accessing that
> > hardware acceleration?  Any timeline?
> > >
> > > I expect that implementing this significant change could be a
> > make-or-break factor in determining whether JavaFX is truly viable and
> > successful on Android.
> > >
> > > Good luck Johan!
> > >
> > > Cheers,
> > >
> > > Felix
> > >
> > >> On 17 Oct 2015, at 19:49, Johan Vos <johan.vos at gluonhq.com> wrote:
> > >>
> > >> As a follow-up on the second part: after about 2 years working on
> > JavaFX on
> > >> Android, I discovered we are not even using Hardware Acceleration. We
> > >> create a SurfaceView and render on that, but it turns out SurfaceView
> is
> > >> never Hardware Accelerated. The positive thing is that this means
> there
> > is
> > >> even more room for optimization :)
> > >>
> > >> - Johan
> > >>
> > >>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos <johan.vos at gluonhq.com>
> > wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Thanks for the suggestions. There are 2 different things:
> > >>>
> > >>> 1. It seems indeed there is not much being cached, so there are
> > definitely
> > >>> improvements possible. It also require e.g. VirtualFlow to use the
> > >>> Node.setCache(true) in order to cache. The combination of this with
> the
> > >>> prism.scrollcacheopt reduces the rendering calls. I think the only
> > penalty
> > >>> is memory, but so far, we didn't run into issues with too high GC
> > activity.
> > >>>
> > >>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100
> > times
> > >>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs
> > 1000ns).
> > >>> I'll have to look into some EGL options.
> > >>>
> > >>> - Johan
> > >>>
> > >>>
> > >>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham <
> james.graham at oracle.com>
> > >>> wrote:
> > >>>
> > >>>> 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
> > >>>> texture.
> > >>>>
> > >>>> Again, are there similar number of invocations of the glDrawElements
> > on
> > >>>> the 2 platforms?
> > >>>>
> > >>>>                       ...jim
> > >>>>
> > >>>>> 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
> > >>>
> >
>