pisces, produceFillAlphas

[Johan Vos]

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.vos at 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.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
>>>
>>>
>>>
>