On 1/19/15, 3:44 AM, Prasant Jalan wrote:
Hi,
I'm running my JavaFX based application (only uses 2D graphics) on Freescale
iMX6Q processor (1.2 GHz x Quad Core). The performance is not up the mark. (I'm
using javaFX build 8u40-b15). My system has framebuffer build of the Vivante
graphic libraries (ver 5.0.11.19959).
First lets make sure you are getting the accelerated stack: add
-Dprism.verbose=true to the command line. The resulting output should indicate
if you are getting accelerated ES support or are quietly falling back to
software rendering.
What version of JavaFX are you using ? There certainly have been some improvements
after the 8u6 release (which is is last current JDK package for ARM with JFX). There
are instructions on how to build and install the current OpenJFX for ARM here
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX>.
The same application when run on an intel i3 processor (4 core, 1.6 GHz each -
Windows 32 bit) performs much better.
Is the difference in performances because of DirectX on Windows and OpenGL on
the embedded ARM? How can I find out the real reason of low performance on my
ARM system (or this is how I should expect it to perform) ?
ARM systems will tend to run slower than comparable Itel if you are just
looking at clock speed - but there are so many other variables in the mix that
it is hard to say what it is the limiting factor. For example - I have seen
some apps that run fine on a sluggish Raspberry Pi because the GPU is fast
enough for the application, and the CPU is not the limiting factor. I have
other apps that run reasonable on my i.MX6, that I can't get a decent frame
rate on the Pi. That same application gets double the FPS on my desktop
machines though not much faster on a intel netbook.
The amount of memory, the bus speed, the CPU speed, and the number of GPU cores
are just a few of the items to consider.
Sometimes the bottleneck is something that does not appear obvious at first.
For example - we cache a lot of textures to speed things up in JFX. A recent
example was using a huge font size - one that exceeded the default cache
limitations (there is a way to override the default settting). Because it was
not cached - it was being regenerated periodically which really showed in the
frame rate.
Complex scene graphs can also cause some computational overhead that is
noticeable on ARM.
Any comments from developers or users who are using Freescale MX6 based system
for their application / tests will be helpful to me.
Regards, Prasant
--
David Hill<[email protected]>
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
