[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: libjfxmedia.so on armv6hf?
From:       Erik De Rijcke <derijcke.erik () gmail ! com>
Date:       2015-03-17 19:55:18
Message-ID: CABO6FzROhvM0G5Uy6X9u6u_8Ma7Oe=NdZaTWK2WwXhgrX0SvNQ () mail ! gmail ! com
[Download RAW message or body]

Why didn't you target drm/kms gl  approach? I realise not all platforms
support this, but it would greatly extend the number of supported
(embedded) platforms in a generic way. A quick google search seems to
indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6).
An RPi drm/kms driver also seems to be in the works and a lot of upcoming
arm gpu's seem to be supported as well. By targeting kms/drm you'd be
supporting a lot of platforms with a single codepath now and in the future.

Unrelated, embedded jfx should use
http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own
bug-risky evdev/raw kernel input implementation. ;)

Now if just somebody would sponser me so I can work fulltime to implement
these things ;)

On Tue, Mar 17, 2015 at 7:39 PM, David Hill <David.Hill@oracle.com> wrote:

> 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 lin=
es
> have blurred and will continue to get more blurry. The Pi was one of a ne=
w
> 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 als=
o
> 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 overhea=
d
> 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 th=
e
> 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 th=
e
> 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 righ=
t
> 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@tidalwave.it>  wrote:
>>
>>  On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick<
>>> felix.bembrick@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 tha=
t
>>>> the
>>>> "community" required to make JavaFX truly viable on iOS, Android and A=
RM
>>>> needs to be about 50-100 times bigger than it currently is.  Without a=
n
>>>>
>>>>  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=C3=A9j=C3=A0 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@tidalwave.it
>>>
>>>
>
> --
> David Hill<David.Hill@Oracle.com>
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should surve=
y
> the world."
> -- George Santayana (1863 - 1952)
>
>
[prev in list] [next in list] [prev in thread] [next in thread]