Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread ngalarneau
Thank you, David, for explaining all that is involved to us desktop-types. 
:-)


Neil




From:   David Hill david.h...@oracle.com
To: openjfx-dev@openjdk.java.net, 
Date:   03/17/2015 02:40 PM
Subject:Re: libjfxmedia.so on armv6hf?
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net



On 3/17/15, 8:04 AM, Erik De Rijcke wrote:
 Why are there limitations on the embedded port of javafx to begin 
with?
 Are there technical reasons for it?
Quite a few actually

The embedded platforms have quite a few features that make them 
difficult. (and I have the bruises to prove it :-)

To start with, an embedded application is usually a single purpose 
instead of a general purpose computing device. Think a kiosk for example. 
When I say general purpose devices - I mean classic desktops and now the 
mobile platforms, where the expectation is that the machine will be used 
for a number of application.

Several of you will say that I am wrong, that a Raspberry Pi for example 
behaves just like a pokey desktop machine. This is a case where the 
lines have blurred and will continue to get more blurry. The Pi was one of 
a new generation of ARM platforms that have a community around them - a 
place where you can both buy a cheap board and get an OS and drivers 
without an NDA. So just as you can make a kiosk using a desktop machine, 
you can also use the PI with XMBC as a media center.

As part of the embedded FX team, our design center was less the Pi 
running with X11, but rather a direct to framebuffer (without the overhead 
and limitations of X11). And the Pi was an after thought for us, a way to 
help out the community. We were targeting a more modern platforms liek the 
i.MX6.

The problem with the direct to framebuffer, and to some extent with the 
rest of the ARM platforms - the platforms are really fractured and it is 
hard to build a working distro. I personally spend many a frustrating day 
trying to get some ARM platform to do something we take for granted on the 
desktop. Starting with OpenGLES drivers, especially ones that would 
talk to the framebuffer (and not X11). The Pi is one of the few examples 
out there of a port that has an easy download that contains most of the 
needed drivers already integrated (and documented). I spent almost a week 
fighting the Beagle Bone Black before getting up. Oh yes - and add on top 
of this all that GL initialization direct to framebuffer is non-standard 
API, so we ended up with 3 code paths for the platforms we were able to 
build.

So in summary it is easy to download a Linux distro. The hardpart is right 
after you do that, and you want the proprietary hardware accelerated 
drivers. There are very few platforms that make this easy.

And the Pi (version 1) is really too slow. The i.MX6 has enough power for 
a real application. The ODROID U3 and XU are also pretty spiffy, but I 
could not get direct to framebuffer working for either of those. If you 
want to use X11 - OpenJFX will probably work for you, and it might even 
have graphical acceleration if the drivers are present and integrated.

Our Embedded team had ARM media as the next big thing to do, but ...

So now we have all of the gstreamer code in the OpenJFX repo. I really 
expect that media on the Pi (1) will probably not work well due to the 
speed of the CPU and the memory bus. Maybe the Pi 2.

Again, you really need the right drivers in place to take advantage of 
hardware accelerated decoding of the media stream.

With the right gstreamer libraries and drivers, I expect the media port 
would not take that long for someone that understands gstreamer.

There might need to be some changes in Monocle to take the video stream 
hand off.

I really would not expect that media would work without some debugging, 
and that after getting the build issues worked out.



 If you think about it, It's arm, so it's embedded. It's x86 so it's
 desktop doesn't make much sense... (atom is embedded, and there are arm
 windows netbooks that are not).

 Anyway, as a workaround, can't openjfx simply be compiled on an arm host
 (so no cross compilation is required) and as such generate the missing
 libraries? Qemu with an arm vm can be used to do that on an x86 host for
 example.

 On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici
 fabrizio.giud...@tidalwave.it  wrote:

 On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick
 felix.bembr...@gmail.com  wrote:

   I really admire guys like this and wish that my own personal 
circumstances
 enabled me to get involved in a similar way but my main concern is 
that
 the
 community required to make JavaFX truly viable on iOS, Android and 
ARM
 needs to be about 50-100 times bigger than it currently is.  Without 
an

 It's my concern too. At this point we're at 20 years of Java, and I 
lived
 them from the very beginning. The idea the community will fix it is a
 déjà vu that, unfortunately, says that in the past the thing didn't 
work
 many times

Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread David Hill

On 3/17/15, 8:04 AM, Erik De Rijcke wrote:

Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?

Quite a few actually

The embedded platforms have quite a few features that make them difficult. 
(and I have the bruises to prove it :-)

To start with, an embedded application is usually a single purpose instead of 
a general purpose computing device. Think a kiosk for example. When I say general purpose 
devices - I mean classic desktops and now the mobile platforms, where the expectation is 
that the machine will be used for a number of application.

Several of you will say that I am wrong, that a Raspberry Pi for example behaves just 
like a pokey desktop machine. This is a case where the lines have blurred and 
will continue to get more blurry. The Pi was one of a new generation of ARM platforms 
that have a community around them - a place where you can both buy a cheap board and get 
an OS and drivers without an NDA. So just as you can make a kiosk using a desktop 
machine, you can also use the PI with XMBC as a media center.

As part of the embedded FX team, our design center was less the Pi running 
with X11, but rather a direct to framebuffer (without the overhead and limitations of 
X11). And the Pi was an after thought for us, a way to help out the community. We were 
targeting a more modern platforms liek the i.MX6.

The problem with the direct to framebuffer, and to some extent with the rest of 
the ARM platforms - the platforms are really fractured and it is hard to build 
a working distro. I personally spend many a frustrating day trying to get some 
ARM platform to do something we take for granted on the desktop. Starting 
with OpenGLES drivers, especially ones that would talk to the framebuffer 
(and not X11). The Pi is one of the few examples out there of a port that has 
an easy download that contains most of the needed drivers already integrated 
(and documented). I spent almost a week fighting the Beagle Bone Black before 
getting up. Oh yes - and add on top of this all that GL initialization direct 
to framebuffer is non-standard API, so we ended up with 3 code paths for the 
platforms we were able to build.

So in summary it is easy to download a Linux distro. The hardpart is right 
after you do that, and you want the proprietary hardware accelerated drivers. 
There are very few platforms that make this easy.

And the Pi (version 1) is really too slow. The i.MX6 has enough power for a 
real application. The ODROID U3 and XU are also pretty spiffy, but I could not 
get direct to framebuffer working for either of those. If you want to use X11 - 
OpenJFX will probably work for you, and it might even have graphical 
acceleration if the drivers are present and integrated.

Our Embedded team had ARM media as the next big thing to do, but ...

So now we have all of the gstreamer code in the OpenJFX repo. I really expect 
that media on the Pi (1) will probably not work well due to the speed of the 
CPU and the memory bus. Maybe the Pi 2.

Again, you really need the right drivers in place to take advantage of hardware 
accelerated decoding of the media stream.

With the right gstreamer libraries and drivers, I expect the media port would 
not take that long for someone that understands gstreamer.

There might need to be some changes in Monocle to take the video stream hand 
off.

I really would not expect that media would work without some debugging, and 
that after getting the build issues worked out.




If you think about it, It's arm, so it's embedded. It's x86 so it's
desktop doesn't make much sense... (atom is embedded, and there are arm
windows netbooks that are not).

Anyway, as a workaround, can't openjfx simply be compiled on an arm host
(so no cross compilation is required) and as such generate the missing
libraries? Qemu with an arm vm can be used to do that on an x86 host for
example.

On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici
fabrizio.giud...@tidalwave.it  wrote:


On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick
felix.bembr...@gmail.com  wrote:

  I really admire guys like this and wish that my own personal circumstances

enabled me to get involved in a similar way but my main concern is that
the
community required to make JavaFX truly viable on iOS, Android and ARM
needs to be about 50-100 times bigger than it currently is.  Without an


It's my concern too. At this point we're at 20 years of Java, and I lived
them from the very beginning. The idea the community will fix it is a
déjà vu that, unfortunately, says that in the past the thing didn't work
many times.

This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
arrives, I'll try the option you and others suggested.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java work. Everywhere.
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it




--
David Hilldavid.h...@oracle.com
Java Embedded Development


Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread Chris Newland
Sorry, I'm a bit confused:

 On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:

 Media and web have not ever been supported or delivered on linux-arm.

So it is possible to build libjfxmedia.so for Linux armv6hf using just
what's in the rt repo?

Thanks,

Chris

On Tue, March 17, 2015 14:46, Kevin Rushforth wrote:
 Not sure what missing stuff you are referring to. All of the JavaFX
 sources for embedded are in the rt repo on openjfx.

 -- Kevin



 Chris Newland wrote:

 Hi Kevin,


 Is there any chance Oracle can release all the missing ARM32 stuff and
 let the community have a go at getting it to work or are there IP /
 licensing issues here?

 I understand that a decision was made to reassign resources but I think
  there's enough brainpower out here in userland to finish the job if
 all the sources were made available.

 Thanks,


 Chris
 @chriswhocodes


 On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:


 Media and web have not ever been supported or delivered on linux-arm.



 Seems that libjfxmedia.so should be excluded by the openZips target.
 David can response further.



 -- Kevin




 Chris Newland wrote:



 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=72026
 7#p7
 20267



 When cross-compiling to armv6hf on an x86-64 Linux system using:



 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:



 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/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


 Is this a simple gradle error or is it not currently possible to
 build some of the JavaFX libraries for ARM?

 Thanks,



 Chris














Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread Erik De Rijcke
Why didn't you target drm/kms gl  approach? I realise not all platforms
support this, but it would greatly extend the number of supported
(embedded) platforms in a generic way. A quick google search seems to
indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6).
An RPi drm/kms driver also seems to be in the works and a lot of upcoming
arm gpu's seem to be supported as well. By targeting kms/drm you'd be
supporting a lot of platforms with a single codepath now and in the future.

Unrelated, embedded jfx should use
http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own
bug-risky evdev/raw kernel input implementation. ;)

Now if just somebody would sponser me so I can work fulltime to implement
these things ;)

On Tue, Mar 17, 2015 at 7:39 PM, David Hill david.h...@oracle.com wrote:

 On 3/17/15, 8:04 AM, Erik De Rijcke wrote:

 Why are there limitations on the embedded port of javafx to begin with?
 Are there technical reasons for it?

 Quite a few actually

 The embedded platforms have quite a few features that make them
 difficult. (and I have the bruises to prove it :-)

 To start with, an embedded application is usually a single purpose
 instead of a general purpose computing device. Think a kiosk for example.
 When I say general purpose devices - I mean classic desktops and now the
 mobile platforms, where the expectation is that the machine will be used
 for a number of application.

 Several of you will say that I am wrong, that a Raspberry Pi for example
 behaves just like a pokey desktop machine. This is a case where the lines
 have blurred and will continue to get more blurry. The Pi was one of a new
 generation of ARM platforms that have a community around them - a place
 where you can both buy a cheap board and get an OS and drivers without an
 NDA. So just as you can make a kiosk using a desktop machine, you can also
 use the PI with XMBC as a media center.

 As part of the embedded FX team, our design center was less the Pi
 running with X11, but rather a direct to framebuffer (without the overhead
 and limitations of X11). And the Pi was an after thought for us, a way to
 help out the community. We were targeting a more modern platforms liek the
 i.MX6.

 The problem with the direct to framebuffer, and to some extent with the
 rest of the ARM platforms - the platforms are really fractured and it is
 hard to build a working distro. I personally spend many a frustrating day
 trying to get some ARM platform to do something we take for granted on the
 desktop. Starting with OpenGLES drivers, especially ones that would
 talk to the framebuffer (and not X11). The Pi is one of the few examples
 out there of a port that has an easy download that contains most of the
 needed drivers already integrated (and documented). I spent almost a week
 fighting the Beagle Bone Black before getting up. Oh yes - and add on top
 of this all that GL initialization direct to framebuffer is non-standard
 API, so we ended up with 3 code paths for the platforms we were able to
 build.

 So in summary it is easy to download a Linux distro. The hardpart is right
 after you do that, and you want the proprietary hardware accelerated
 drivers. There are very few platforms that make this easy.

 And the Pi (version 1) is really too slow. The i.MX6 has enough power for
 a real application. The ODROID U3 and XU are also pretty spiffy, but I
 could not get direct to framebuffer working for either of those. If you
 want to use X11 - OpenJFX will probably work for you, and it might even
 have graphical acceleration if the drivers are present and integrated.

 Our Embedded team had ARM media as the next big thing to do, but ...

 So now we have all of the gstreamer code in the OpenJFX repo. I really
 expect that media on the Pi (1) will probably not work well due to the
 speed of the CPU and the memory bus. Maybe the Pi 2.

 Again, you really need the right drivers in place to take advantage of
 hardware accelerated decoding of the media stream.

 With the right gstreamer libraries and drivers, I expect the media port
 would not take that long for someone that understands gstreamer.

 There might need to be some changes in Monocle to take the video stream
 hand off.

 I really would not expect that media would work without some debugging,
 and that after getting the build issues worked out.




 If you think about it, It's arm, so it's embedded. It's x86 so it's
 desktop doesn't make much sense... (atom is embedded, and there are arm
 windows netbooks that are not).

 Anyway, as a workaround, can't openjfx simply be compiled on an arm host
 (so no cross compilation is required) and as such generate the missing
 libraries? Qemu with an arm vm can be used to do that on an x86 host for
 example.

 On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici
 fabrizio.giud...@tidalwave.it  wrote:

  On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick
 felix.bembr...@gmail.com  wrote:

   I really 

Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread Erik De Rijcke
Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?

If you think about it, It's arm, so it's embedded. It's x86 so it's
desktop doesn't make much sense... (atom is embedded, and there are arm
windows netbooks that are not).

Anyway, as a workaround, can't openjfx simply be compiled on an arm host
(so no cross compilation is required) and as such generate the missing
libraries? Qemu with an arm vm can be used to do that on an x86 host for
example.

On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici 
fabrizio.giud...@tidalwave.it wrote:

 On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick 
 felix.bembr...@gmail.com wrote:

  I really admire guys like this and wish that my own personal circumstances
 enabled me to get involved in a similar way but my main concern is that
 the
 community required to make JavaFX truly viable on iOS, Android and ARM
 needs to be about 50-100 times bigger than it currently is.  Without an


 It's my concern too. At this point we're at 20 years of Java, and I lived
 them from the very beginning. The idea the community will fix it is a
 déjà vu that, unfortunately, says that in the past the thing didn't work
 many times.

 This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
 arrives, I'll try the option you and others suggested.


 --
 Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
 We make Java work. Everywhere.
 http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it



Re: libjfxmedia.so on armv6hf?

2015-03-17 Thread Kevin Rushforth
Not sure what missing stuff you are referring to. All of the JavaFX 
sources for embedded are in the rt repo on openjfx.


-- Kevin


Chris Newland wrote:

Hi Kevin,

Is there any chance Oracle can release all the missing ARM32 stuff and let
the community have a go at getting it to work or are there IP / licensing
issues here?

I understand that a decision was made to reassign resources but I think
there's enough brainpower out here in userland to finish the job if all
the sources were made available.

Thanks,

Chris
@chriswhocodes

On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
  

Media and web have not ever been supported or delivered on linux-arm.


Seems that libjfxmedia.so should be excluded by the openZips target.
David can response further.


-- Kevin



Chris Newland wrote:



In reference to
http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p7
20267


When cross-compiling to armv6hf on an x86-64 Linux system using:


gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:


file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/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


Is this a simple gradle error or is it not currently possible to build
some of the JavaFX libraries for ARM?

Thanks,


Chris




  



  


Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Kevin Rushforth

Media and web have not ever been supported or delivered on linux-arm.

Seems that libjfxmedia.so should be excluded by the openZips target. 
David can response further.


-- Kevin


Chris Newland wrote:

In reference to
http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267

When cross-compiling to armv6hf on an x86-64 Linux system using:

gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:

file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/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

Is this a simple gradle error or is it not currently possible to build
some of the JavaFX libraries for ARM?

Thanks,

Chris


  


Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Chris Newland
Hi Kevin,

Is there any chance Oracle can release all the missing ARM32 stuff and let
the community have a go at getting it to work or are there IP / licensing
issues here?

I understand that a decision was made to reassign resources but I think
there's enough brainpower out here in userland to finish the job if all
the sources were made available.

Thanks,

Chris
@chriswhocodes

On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
 Media and web have not ever been supported or delivered on linux-arm.


 Seems that libjfxmedia.so should be excluded by the openZips target.
 David can response further.


 -- Kevin



 Chris Newland wrote:

 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p7
 20267


 When cross-compiling to armv6hf on an x86-64 Linux system using:


 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:


 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/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


 Is this a simple gradle error or is it not currently possible to build
 some of the JavaFX libraries for ARM?

 Thanks,


 Chris









Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Fabrizio Giudici
On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth  
kevin.rushfo...@oracle.com wrote:


Unlikely without help from the community, given that FX itself is no  
longer supported on linux-arm. We currently have no plan to add such  
support.


Quite annoying stuff. BTW, I've just read  
http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367


It's quite curious. I've just ordered a Raspberry Pi 2 and was planning  
about writing a media center prototype with some ideas in mind. In the  
past years I did lots of stuff with imaging and media, and was with Swing.  
I struggled with tons of incomplete features in the imaging and movie  
APIs, lots of additional libraries in order to have a decent modern UI  
(with animations and such), because Java didn't offer them out of the box.  
In the end I quit because it was frustrating to always be forced to fix  
something at the basics level. I mean, I just wanted to focus on the  
application. Now, fast forward some years and we have that Java FX, with  
bells and whistles. I supposed I could at last enjoy writing an app on the  
RPI without worrying about missing, incomplete, partially unsupported  
stuff, but I was wrong. It seems that no matter Sun or Oracle, there's a  
sort of curse preventing the Java ecosystem to fully work on the reference  
rich UI hardware.


Sorry for the rant, nothing against people of course, but that's just my  
feelings at the moment.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java work. Everywhere.
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it


Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Felix Bembrick
Yes Fabrizio, I agree with you.  First it was iOS, then Android and now
ARM. Oracle the company seem to view JavafX or their support for it as just
a fancy Swing replacement to run exclusively on desktop operating systems
like Windows, MacOS and Linux.  But can we even trust that they will
continue to invest in those platforms?  The problem seems to be as simple
that Oracle makes little or no money directly from JavaFX and being a very
profit focused company, why would they care about it?

Their attitude now is that is you want JavaFX to actually work on anything
other than the desktop (i.e. on all the modern devices that most people are
actually using these days) then the community must step-up and make it
happen.  Thats a very disappointing and concerning attitude to say the
least!

Fortunately some in the community, notably Johan Vos and his company Gluon
and Niklas Therning with RoboVM have stepped-up to try to fill this void
but we are talking about a handful of people with shoestring budgets trying
to get sophisticated technology working on an enormous range of complex and
highly fragmented modern devices.  How can they compete with a company like
Qt which exists *only* to develop and sell Qt and have at least one hundred
developers working on each of the iOS and Android ports and already have
viable mobile apps using Qt selling out there in the marketplace.

I really admire guys like this and wish that my own personal circumstances
enabled me to get involved in a similar way but my main concern is that the
community required to make JavaFX truly viable on iOS, Android and ARM
needs to be about 50-100 times bigger than it currently is.  Without an
overall corporation paying the wages of these people, how is that ever
going to happen?  And by truly viable I mean making JavaFX a technology
that can be used for *serious commercial application development *on all
those platforms.  Pretty gauges and simple square-based games are not
enough to sustain or interest software houses to adopt JavaFX to develop
their products and until that happens, JavaFX is going to struggle...

Felix

On 17 March 2015 at 10:53, Fabrizio Giudici fabrizio.giud...@tidalwave.it
wrote:

 On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth 
 kevin.rushfo...@oracle.com wrote:

  Unlikely without help from the community, given that FX itself is no
 longer supported on linux-arm. We currently have no plan to add such
 support.


 Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/
 forums/viewtopic.php?f=81t=97367

 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning
 about writing a media center prototype with some ideas in mind. In the past
 years I did lots of stuff with imaging and media, and was with Swing. I
 struggled with tons of incomplete features in the imaging and movie APIs,
 lots of additional libraries in order to have a decent modern UI (with
 animations and such), because Java didn't offer them out of the box. In the
 end I quit because it was frustrating to always be forced to fix something
 at the basics level. I mean, I just wanted to focus on the application.
 Now, fast forward some years and we have that Java FX, with bells and
 whistles. I supposed I could at last enjoy writing an app on the RPI
 without worrying about missing, incomplete, partially unsupported stuff,
 but I was wrong. It seems that no matter Sun or Oracle, there's a sort of
 curse preventing the Java ecosystem to fully work on the reference rich UI
 hardware.

 Sorry for the rant, nothing against people of course, but that's just my
 feelings at the moment.

 --
 Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
 We make Java work. Everywhere.
 http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it



Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Kevin Rushforth
Unlikely without help from the community, given that FX itself is no 
longer supported on linux-arm. We currently have no plan to add such 
support.


-- Kevin


Felix Bembrick wrote:

Will they ever be supported?

On 17 March 2015 at 10:14, Kevin Rushforth kevin.rushfo...@oracle.com 
mailto:kevin.rushfo...@oracle.com wrote:


Media and web have not ever been supported or delivered on linux-arm.

Seems that libjfxmedia.so should be excluded by the openZips
target. David can response further.

-- Kevin



Chris Newland wrote:

In reference to

http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267

http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267

When cross-compiling to armv6hf on an x86-64 Linux system using:

gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:

file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/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

Is this a simple gradle error or is it not currently possible
to build
some of the JavaFX libraries for ARM?

Thanks,

Chris


 





Re: libjfxmedia.so on armv6hf?

2015-03-16 Thread Felix Bembrick
Will they ever be supported?

On 17 March 2015 at 10:14, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:

 Media and web have not ever been supported or delivered on linux-arm.

 Seems that libjfxmedia.so should be excluded by the openZips target. David
 can response further.

 -- Kevin



 Chris Newland wrote:

 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=
 97367p=720267#p720267

 When cross-compiling to armv6hf on an x86-64 Linux system using:

 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:

 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/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

 Is this a simple gradle error or is it not currently possible to build
 some of the JavaFX libraries for ARM?

 Thanks,

 Chris







libjfxmedia.so on armv6hf?

2015-03-16 Thread Chris Newland
In reference to
http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267

When cross-compiling to armv6hf on an x86-64 Linux system using:

gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:

file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/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

Is this a simple gradle error or is it not currently possible to build
some of the JavaFX libraries for ARM?

Thanks,

Chris