pisces, produceFillAlphas

Tue Nov 17 19:59:39 UTC 2015

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
> >>>
>