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