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