pisces, produceFillAlphas

[Jim Graham]

Ignore that last question - I just realized that you already answered 
it, my apologies...

			...jim

On 10/15/15 3:18 PM, Jim Graham 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
>>
>>