libjfxmedia.so on armv6hf?
ngalarneau at ABINITIO.COM
ngalarneau at ABINITIO.COM
Tue Mar 17 18:46:27 UTC 2015
Thank you, David, for explaining all that is involved to us desktop-types.
From: David Hill <David.Hill at Oracle.com>
To: openjfx-dev at openjdk.java.net,
Date: 03/17/2015 02:40 PM
Subject: Re: libjfxmedia.so on armv6hf?
Sent by: "openjfx-dev" <openjfx-dev-bounces at 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
> 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
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
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
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
> On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici<
> Fabrizio.Giudici at tidalwave.it> wrote:
>> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick<
>> felix.bembrick at gmail.com> wrote:
>> I really admire guys like this and wish that my own personal
>>> enabled me to get involved in a similar way but my main concern is
>>> "community" required to make JavaFX truly viable on iOS, Android and
>>> needs to be about 50-100 times bigger than it currently is. Without
>> It's my concern too. At this point we're at 20 years of Java, and I
>> 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
>> 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.giudici at tidalwave.it
David Hill<David.Hill at Oracle.com>
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey
-- George Santayana (1863 - 1952)
NOTICE from Ab Initio: This email (including any attachments) may contain
information that is subject to confidentiality obligations or is legally
privileged, and sender does not waive confidentiality or privilege. If
received in error, please notify the sender, delete this email, and make
no further use, disclosure, or distribution.
More information about the openjfx-dev