pisces, produceFillAlphas

[Johan Vos]

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.graham at 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.graham at oracle.com
>> <mailto: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...
>>
>>                              ...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
>>
>>
>>