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. >> >> 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) 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.
