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 

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.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
"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 Hill<david.h...@oracle.com>
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
-- George Santayana (1863 - 1952)

Reply via email to