libjfxmedia.so on armv6hf?

Tue Mar 17 18:46:27 UTC 2015

Thank you, David, for explaining all that is involved to us desktop-types. 
:-)

Neil

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 
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.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 
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.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 
the world."
-- 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. 