chien.yang at oracle.com
Thu Oct 15 19:42:28 UTC 2015
This optimization is buggy but to see whether it helps you can try setting
Please see JDK-8093860 for reason why it was disabled:
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.graham at 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...
>> On 10/15/15 4:27 AM, Johan Vos wrote:
>>> After spending lots of time optimizing JavaFX on iOS, I am now at the
>>> 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.
>>> - Johan
More information about the openjfx-dev