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