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.bembr...@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....@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....@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.gra...@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.gra...@oracle.com >>>>> <mailto:james.gra...@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 >>>
