james.graham at oracle.com
Thu Oct 15 22:18:50 UTC 2015
Ignore that last question - I just realized that you already answered
it, my apologies...
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
> Again, are there similar number of invocations of the glDrawElements on
> the 2 platforms?
> 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
>> 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...
>> 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
>> 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
>> (implemented in native-prism/NativePiscesRasterizer.c)
>> On average, calling this native function on an iPhone 6 takes
>> 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