Re: JavaFX graphic performance slow on Mac? Clock app

[Jim Graham]

Hi Tobi,

Can you share your small clock app?  Perhaps file a bug and attach the 
source?


Also, what version of MacOS are you running on what hardware?  (And 
compared to what version of Windows on what hardware?)


...jim

On 7/7/15 4:32 AM, Tobias Bley wrote:



Hi,

currently our experiences with JavaFX on Mac are very disappointing. While 
JavaFX on Windows runs very good with low cpu usage, JavaFX on Mac via  Java 8 
doesn’t perform well. I created a little clock app which uses between 25% and 
80% cpu usage. But what’s the reason for? I though JavaFX rendering pipeline 
works on the graphic device? So why there is such a traffic on the CPU?




Best regards,
Tobi

Re: Cross build JavaFX for iMX6

[Daniel.]

Hi all,

I'm still trying to run JavaFX on iMX6 using fsl-image-gui image from Yocto
Dizzy with DISTRO_FEATURES_remove = x11 wayland directfb. After compiling
the image and javafx I tried to run Modena.jar with the script provided by
Jörg.

I'm facing this exception:

Java HotSpot(TM) Client VM warning: You have loaded library
/opt/armv6hf-sdk/rt/lib/arm/libjfxwebkit.so which might have disabled stack
guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c
libfile', or link it with '-z noexecstack'.
Jul 07, 2015 8:32:06 PM javafx.scene.control.Control loadSkinClass
SEVERE: Failed to load skin 'com.sun.javafx.scene.web.skin.HTMLEditorSkin'
for control SamplePage$1@1986d5
java.lang.UnsatisfiedLinkError:
/opt/armv6hf-sdk/rt/lib/arm/libjfxwebkit.so:
/opt/armv6hf-sdk/rt/lib/arm/libjfxwebkit.so: wrong ELF class: ELFCLASS64
(Possible cause: architecture word width mismatch)

So I browse to fresh built sdk, and find this:
[geckos@csi24 build]$ find . -name *.so -exec file {} + | grep x86-64
./armv6hf-sdk/rt/lib/arm/libgstreamer-lite.so:   ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=653c81ccc1dfd6fedf946c34a4c2e07d6d3cbed5, not stripped
./armv6hf-sdk/rt/lib/arm/libfxplugins.so:ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=b18524ebc26cd8381b0c33cb2d91a4de68a721fa, not stripped
./armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped
./armv6hf-sdk/rt/lib/arm/libjfxwebkit.so:ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=3143cf3f8ed8d00c2c4048fb835fb3fd86b68f79, stripped

It seems that this libraries ar not being cross compiled, is that normal?
The another libraries seems good:
[geckos@csi24 build]$ find . -name *.so -exec file {} + | grep ARM
./armv6hf-sdk/rt/lib/arm/libglass.so:ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=8efdb3236c43fc4abaaae956ffba0bfca336c28b, not stripped
./armv6hf-sdk/rt/lib/arm/libprism_es2_eglfb.so:  ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=25264a33f919a3a925ef2d2f8ec5d4a10bfbdbf9, not stripped
./armv6hf-sdk/rt/lib/arm/libglass_monocle_x11.so:ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=d1735e47b13e56d58d4e9b7a7f6dee338d9f, not stripped
./armv6hf-sdk/rt/lib/arm/libdecora_sse.so:   ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=8052ae5d7f230ee0629743f9ee421371e3522538, not stripped
./armv6hf-sdk/rt/lib/arm/libprism_common.so: ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=658886a9bead9068f4111679e8f5f350386d235b, not stripped
./armv6hf-sdk/rt/lib/arm/libjavafx_font.so:  ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=c84058878ffaeebf60be04eb0d138ecf3fdf5cd1, not stripped
./armv6hf-sdk/rt/lib/arm/libglass_monocle.so:ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=ea65233624f7cb0d220ce974aa122866fff659a2, not stripped
./armv6hf-sdk/rt/lib/arm/libprism_es2_monocle.so:ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=6827d044682876f8ace57cfdc3417e026688701c, not stripped
./armv6hf-sdk/rt/lib/arm/libprism_sw.so: ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=eba0d9ddc0bc463e92008e90ded9a3ff17295337, not stripped
./armv6hf-sdk/rt/lib/arm/libjavafx_font_pango.so:ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=be19332b8b460d6e97486cf3d91cf056fefa550b, not stripped
./armv6hf-sdk/rt/lib/arm/libjavafx_font_freetype.so: ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=a2e42e950718d3c926ced01a014fa6475347cdf2, not stripped
./armv6hf-sdk/rt/lib/arm/libjavafx_iio.so:   ELF 32-bit LSB shared
object, ARM, EABI5 version 1 (SYSV), dynamically linked,
BuildID[sha1]=1f879805f5dca1ce97d4d2798b8f40a32eeb547a, not stripped
[geckos@csi24 build]$

To compile run this:
gradle -PCOMPILE_TARGETS=armv6hf

Best regards,
- dhs


2015-07-06 16:47 GMT-03:00 Daniel. danielhi...@gmail.com:

 I see, so I'll keep usign armv6hf, I'm compiling a new fsl-image-gui from
 scratch (have to update yocto) using Dizzy release. What version of Yocto
 you're using and what image you use for testing?

 Best regards,

 - dhs

 2015-07-06 10:57 GMT-03:00 Kevin Rushforth kevin.rushfo...@oracle.com:

  We do most of our (limited) testing on iMX6 using armv6hf binaries, but
 armv7hf should work, too.

 

Re: JavaFX graphic performance slow on Mac? Clock app

[Robert Krüger]

On Tue, Jul 7, 2015 at 1:32 PM, Tobias Bley t...@ultramixer.com wrote:



 Hi,

 currently our experiences with JavaFX on Mac are very disappointing. While
 JavaFX on Windows runs very good with low cpu usage, JavaFX on Mac via
 Java 8 doesn’t perform well. I created a little clock app which uses
 between 25% and 80% cpu usage. But what’s the reason for? I though JavaFX
 rendering pipeline works on the graphic device? So why there is such a
 traffic on the CPU?


Hi,

I had the exact same experience with a super-simple app that just animates
a circle and was not able to get it to run smoothly on the Mac at least not
for window sizes that were not very small and cpu load was also much higher
than expected for an app that only does things which I thought were
accelerated.

See https://bugs.openjdk.java.net/browse/JDK-8088396

Doesn't look very encouraging.

Cheers,

Robert