JavaFX SDK 8 on BeagleBoard

Wed Jan 30 08:04:44 PST 2013

On 12/24/12 Dec 24, 7:05 AM, Conrad Winchester wrote:
> Hi,
>
> I have been experimenting with JavaFX on the Beagleboard xM for a while now. I also have a raspberry Pi, but find it's power supply instabilities and weaknesses very frustrating, and so much prefer the more stable beaglebord for tinkering. In particular I am working with Tinkerforge equipment that really makes the poor old Pi expire :-(
>
> The JDK8 JavaFX ARM Preview has just been released for the Raspberry Pi. I have it running, but , as stated above, using the raspberry pi with anything attached to the USB without a powered hub is nigh on impossible and so I would love to use it on the Beagleboard.
>
> Unfortunately it does not seem to work. In fact the Beagleboard does not even recognise any of the executables as files in the JDK8 JavaFX ARM release. If I cd /opt/jdk1.8.0/bin and do a ./java -version I get the following error message
>
> -sh: ./java: No such file or directory
>
> even though if I do an ls, I can definitely see it there.
>
> Is this a sign of things to come? Are the various linux/arm chip configurations so different that there will always be a multitude of different Java ARM installs to cater for every combination? Or is there a magic thing that I can do to solve the issue?
>
> Any help would be greatly appreciated.

Conrad,

    There are several issues with embedded hardware, so bear with me as I explain some things (if only to get the terminology straight :-). While I suspect you know some of this, perhaps some of the others on the list will enjoy a read.

Before I get to graphics - there is the hard float/soft float ABI issue. Most platforms right now use the older soft float ABI. A few have moved the hard float ABI (the PI provides downloads for both). One problem for the hard float is often there is a hard float OS disto available, but the black box vendor graphics drivers are not available yet - meaning you only get the much, much slower graphics. The two ABI are not interchangeable. Interestingly - on the PI where I have the ability to directly compare hard/soft performance - the hard float distro (wheezy) is about 20% faster in some of our rendering benchmarks. This increase is probably not just the cleaner ABI in our code, but likely the result of the GLES drivers and all of the FP values it throws around.

The Beagle JFX preview is soft float. I am not aware of a full up hard float distro AND graphics drivers for the Beagle (yet). This preview is dated now, and will only be updated through the SE8 beta.

The PI JFX preview (now part of the SE8 beta) uses the hard float ABI. This beta will not work on the Beagle.

There is a bandwidth crunch in engineering, and so for now, the SE8 beta is available in the hard float ABI only. This means that at least for the next couple of months - the PI is the only way to get the newer drops of JFX.

On to graphics.

There are several logical paths for us to get pixels on the screen, and here are four of them:

    * Direct to Framebuffer, using OpenGLES v2, or software only rendering
    * Via X11 using OpenGLESv2 or client side software only rending.

We believe our primary market in embedded is for OpenGLESv2  "Direct to Framebuffer" (FB). Taking X11 out of the path reduces overhead, and speeds rendering. The applications we are likely to see from vendors using the product would be "full screen". The challenge for FB rendering is how to get to the FB.

The problem with GLES drivers is that they are platform specific, and not all of them support EGL/GLESv2 direct to the FB. Even on "the same family" GPUs, you will find differences in support, for example direct to FB is supported on the Beagle, but not on the Panda (at least last I looked), even though both use PVR drivers. Different GPU "families" can have different EGL startup sequences - as the EGL standard does not specify the startup sequence for FB, only for X11. Each of the "families" seem to have a slightly different way of doing those first few steps - some requiring platform specific calls to do so. (Beagle xM, I can use a "EGL-NULL", passing in NULL to a couple of calls and the right thing happens, for PI, there are several "dispman" calls that are needed.

In addition to the EGL/GLES, there are a number of other things we need to be able to do to get support right. These involve things like overlaying a mouse cursor for example. So far, none of these additional items seem to be common across hardware vendors.

At least input is common across Linux. For our non-X11 paths - we rely on directly detecting/reading the input devices. A challenge there is that not all touch devices behave the same, and we are still learning there.

For our initial SE8 release we have been concentrating on Beagle xM and PI. I have other boards I would like to be able to say are "Known to work". but that would require engineering bandwidth (and I am including SQE) that can be easily stretched when you start laying out the number of boards I want :-).

In the case of the "software only", we are talking about our common software rendering path, which does not use any platform specific calls for rendering except to upload a fully rendered "texture" (basically the contents of a window to the display. This "fallback" rendering is good enough for simple scene graphs, but would not be my first choice.

The embedded team has designed our "Glass" implementation (the layer that interacts with the window manager, or in our case *is* the window manager) and our "Prism" implementation (the rendering engine) with a certain amount of flexibility in mind, hoping that we can continue to add detection/initialization paths for hardware as we get them, and have time to implement them. We are looking forward to the OSS of this code, because we know that there are a number of people out there who will be willing and able to help up add new platforms to our framework.

  As much as I want to have one of every board out there - we know that is impossible. And there are so many nifty new boards out there... I love browsing though the catalogs and reviews, and seeing a "HDMI stick" for example, and wishing I had one, and the time to port JFX to it.

Hope that helps,
     Dave

PS. to help with PI power issues, start with a powered USB hub, and then add a beefier power supply. The powered hub took away most of my stability issues, the 2A ps the rest.

-- 
David Hill <David.Hill at Oracle.com>
Java Embedded Development

America's greatest strength, and its greatest weakness, is our belief in second chances, our belief that we can always start over, that things can be made better.
-- Anthony Walton