Johan? I really need this kind of information and you seem to be the most qualified person to provide it.
Cheers, Felix > On 31 Oct 2015, at 19:23, Felix Bembrick <felix.bembr...@gmail.com> wrote: > > Hi Johan, > > Now that your workload has hopefully lessened a bit after J1, do you think > you could find some time to address this question of mine from earlier? > > 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 >>>>
