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 Hill<david.h...@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)
