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.bembr...@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.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 > >>> >
